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

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

localtime() fills the gap between the two.

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. 

BL> Then why the fuck does my Borland book have some functions like
BL> ctime() shown portable across DOS/UNIX/Windows/ANSI and others like
BL> strftime() with UNIX left out?

Borland didn't make the ISO C or POSIX standards.  If you use their books
instead of the standards, you need to have a couple of grains of salt
handy.  Recently, Roy was claiming that stricmp() was ANSI. It isn't.  In
your case, Borland is saying that something isn't "UNIX", but
what do they mean by that?  Probably that it isn't part of the interface
created 20 years ago.

BL> I assume that means if I set the
BL> compiler to ANSI and press the button, the EXE I get won't work on
BL> UNIX? 

Ye gads!  The EXE you get won't work on Linux in a million years! They're
completely different formats.  Only the source code will port.

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

PM> Yes you can!

BL> How? What function will turn the "seconds since 1970" long into a
BL> time string "1-01-70"? 

localtime() followed by strftime().  Assuming a POSIX environment, where
time_t and "seconds since 1970" are presumed identical.

BL> Paul told me to define...

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

Correct.

BL> qsort(list, n, 80, sort);

I didn't say that.  You didn't ask me about the qsort call.  That
"80" is incorrect.  It should be sizeof(char *).

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

And xysort works successfully too.  BFN.  Paul.
@EOT:

---