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).



 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"? I'm buggered if I can find one!
Anyway, I've

 BL> already writtren one.



Yes, strftime() takes a tm struct, so all you need to do is convert the
time_t variable to a tm struct using localtime() and the pass it to
strftime(). You can use something like:



#include 

#include 

#include 

#include 

#include 



int main(void)

    {

    struct stat s;

    char        buff[20];



    stat("c:\\config.sys", &s);

    strftime(buff, sizeof(buff), "%d-%m-%y", localtime(&s.st_ctime));

    printf(buff);



    return(EXIT_SUCCESS);

    }



 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?



I would imagine that when Borland say UNIX they're referring to pre-ANSI
K&R. In that case strftime() probably isn't part of K&R, however,
since the ANSI standard has been around for about 8 years now, the
compilers under UNIX do understand ANSI functions.



 BL> I assume that means if I set the compiler to ANSI and press the

 BL> button, the EXE I get won't work on UNIX?



The EXE you generate under DOS won't work under UNIX. What you can do is to

copy your source code to a UNIX system and recompile it there without

having to change your code.



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



What I mean is that the compilers under UNIX understand C source code

that conforms to the ANSI standard.



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

 PM>> UNIX system?



 BL>   I read that Borland is about to release Delphi for C, so I thought

 BL> I'd give C another run in light of my greatly advanced knowledge of

 BL> Pascal.



Since Delphi is Pascal, I've got no idea what Delphi for C is!



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



 BL>   char *list[512];



 BL>   and allocate memory       list[n] = malloc(80);

 BL>                             strcpy(list[n], shithead);



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



 BL>   Paul told me to define...



 BL>   int sort((const void*)a, (const void*)b) {

 BL>     return (strcmp(*(char **)a, *(char **)b));     {



Paul is correct.



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

                     ^^^^



If you're trying to sort using pointers, defining the element length as 80

is wrong. You need to define it as the length of a pointer:



    qsort(list, n, sizeof(list[0]), sort);



 BL>   Paul is as much use as a spare wheel on a unicycle, so I'm desperate

 BL> enough to ask you...



I'm silly enough to answer.





Paul



--- GoldED 2.42.G0214+