PE>> I checked the posix standard, stat() is in there, operates on
 PE>> a filename, include  and  to get it.
 PE>> The dates are all of type time_t, so you can use strftime() on
 PE>> them.

 BL> Borland says the opposite about their stat struct,

 PM> I looked up the Borland library manual and had a look in the
 PM> stat.h header and all the dates returned are type time_t. It
 PM> certainly looks like Borland behaves the same was as the POSIX
 PM> standard in this case. 

 BL> but strftime() won't work in Unix anyway.

  I got that crossed up. What I meant was that Borland defines time_t
as a long that won't work with strftime() which actually uses a tm
struct (a whole lot of shorts and stuff).

 BL> but strftime() won't work in Unix anyway.

 PM> Errr, Bob, strftime() is an ANSI defined function and will work
 PM> on any ANSI compliant compiler *including* those under UNIX. 

  Then why the fuck does my Borland book have some functions like
ctime() shown portable across DOS/UNIX/Windows/ANSI and others like
strftime() with UNIX left out? I assume that means if I set the
compiler to ANSI and press the button, the EXE I get won't work on
UNIX? 

  I don't know what you mean by ANSI compliant compiler under UNIX.

 BL> If you just call stat() and use the struct as time_t you will
 BL> get daylight savings time for New York (that's what *I* got,
 BL> anyway).

 PM> I assume you're not using the actual structure as a variable of
 PM> time_t? The three time fields in the structure are type time_t
 PM> in the Borland headers.

  That's what I mean. I refuse to use the correct terminology in case
I turn into a programmer. I'd rather be a proper engineer.

 PM> At least they are with the version I've got (version 4.0 -- ie.
 PM> fairly old). What version of Borland C are you running anyway? 

  3.1 and 4.02.

 BL> But I can't use the time_t variable anyway, in UNIX.

 PM> Yes you can!

  How? What function will turn the "seconds since 1970" long into a
time string "1-01-70"? I'm buggered if I can find one! Anyway, I've
already writtren one.

 PM> Why this emphasis on UNIX anyway? Are you actually running a
 PM> UNIX system? 

  I read that Borland is about to release Delphi for C, so I thought
I'd give C another run in light of my greatly advanced knowledge of
Pascal. At the same time, Paul mentioned he needed a TIC that would
run under UNIX, and TIC seemed like an interesting little thingie I
could incorporate into TinyPoint anyway.

  Paul's the dickhead who intends to use UNIX. I plan to amputate my
leg with a rusty knife, and then become a buddhist monk and bury
myself alive. Or I might use OS/2. I can't make up my mind. It all
sounds so good.

  While you're there... why don't you make yourself useful and answer
a real question about C instead of trying to show me how silly I am. I
already know that...

  QSORT()

  If I define the list function as:

  char  list[256][80];

  and then the sort function as

  int sort((const void *)a , (const void *)b)  {
      return (strcmp((char*) a, (char *) b));  }

  and then use 

  qsort(list, n, 80, sort);           it works...

  BUT, I'd rather declare an arror of pointers:

  char *list[512];

  and allocate memory       list[n] = malloc(80);
                            strcpy(list[n], shithead);

  So... what the hell do I use to run qsort()?

  Paul told me to define...

  int sort((const void*)a, (const void*)b) {
    return (strcmp(*(char **)a, *(char **)b));     {

  qsort(list, n, 80, sort);

  It don't lock the computer, but it don't sort nothin' neither. 

  Paul is as much use as a spare wheel on a unicycle, so I'm desperate
enough to ask you...

  How do I use qsort() to sort an array of pointers to strings?

Regards,
Bob
 
___ Blue Wave/QWK v2.12
@EOT:

---