Just to follow up on my posted patch (already checked in by Daniel):

>On Feb 9, 19:05, I wrote:
>>For some reason test 141 fails on 64-bit Irix but everything passed on
>>64-bit AIX.
>[...]
>
>It's dangerous to cast pointers, particularly when working with 64-bits systems.
>The following patch fixes the problem with test 141 on SGI/IRIX 64-bit builds.
>
>-Tor
>
>Index: ftp.c
>===================================================================
>RCS file: /repository/curl/lib/ftp.c,v
>retrieving revision 1.225
>diff -u -p -r1.225 ftp.c
>--- ftp.c 9 Feb 2004 07:52:36 -0000 1.225
>+++ ftp.c 12 Feb 2004 19:11:54 -0000
>@@ -2238,11 +2238,12 @@ CURLcode ftp_perform(struct connectdata
> #ifdef HAVE_STRFTIME
> if(data->set.get_filetime && (data->info.filetime>=0) ) {
> struct tm *tm;
>+ time_t clock = (time_t) data->info.filetime;
> #ifdef HAVE_GMTIME_R
> struct tm buffer;
>- tm = (struct tm *)gmtime_r((time_t *)&data->info.filetime, &buffer);
>+ tm = (struct tm *)gmtime_r(&clock, &buffer);
[snipped]

In case anyone wonders why the original code was bad, on IRIX64 we have:
sizeof time_t: 4
sizeof long : 8
and thus one cannot cast a pointer to one to a pointer of the other.
(on AIX 64 time_t is also 8 bytes, that's why test 141 didn't fail there)

As a general rule, one should *never* cast pointers, except when either
1) the data pointed to will not be referred at all
2) the data handling is truly data type independent, e.g. when it's handled
   as a byte-stream to be memcpy'ed or whatever. However, in those cases you
   would instead let the function argument be a void pointer, and skip the
   casting altogether (and handle the magic inside the called function).
The safe way is to cast the data instead, and, if a pointer is needed, take
the address of the new variable (and that is what the above patch does :-)

-Tor
Received on 2004-02-13