Roy is right...
Willy-nilly throwing casts on data objects just to satisfy some
anal-retentive urge to not see any warnings appearing during a
compile is the absolute WRONG thing to do when it comes
to porting 32-bit code to 64-bit platforms.
The situation is NOT as simple as it was when 32-bits hit
the scene and everybody had to port all the 16-bit stuff.
I've been working with 64 bit for quite some time and I can
tell you that there are still many goblins lurking in this
department and many assumptions that are not true.
Example...
> Roy wrote...
> It is far safer to cast module-provided data from int
> up to 64 bits than it is to cast it down from 64 bit to int.
Probably... but there is an assumption being made there
on Roy's part. He is assuming that the cast will automatically
clear the high order 32 bits. One SHOULD be able to 'assume'
that in order not to violate the 'principle of least astonishment'
but, unfortunately, on some current 64 platforms this
is not the case.
A simple cast of an 'int' to a 'long long' ( or the equivalent
64 bit wide data item ) will NOT 'clear' all the high order bits
that reach the target.
I am not going to name any names here on this (public) forum
but all I can tell you is that if you think a simple typecast
in ANY direction ( up or down ) on a 64 bit platform is
automatically setting or clearing high/low order bits...
think again.
Consult with your chip manufacturer and read all defect
reports and read your 64 bit compiler or assembler
manual carefully.
Also... take a (careful) look at the ASM code being
produced. Trust... but verify.
Roy is absolutely right when he says that the only
way to go is from 'the bottom up' ( and keep those
chip and compiler manuals and defect reports close by ).
Yours...
Kevin Kiley
In a message dated 10/22/2004 8:20:38 PM Central Daylight Time, [EMAIL PROTECTED] writes:
> The precursor to this patch "[PATCH] WIN64: httpd API changes"
> was posted 10/7 so I thought we had had suitable time for
> discussion. I have addressed the one issue that was raised.
That explains why I didn't see it -- I was in Switzerland.
> There have also been several other threads on the httpd & apr
> lists and the feedback I had received indicated the it was
> appropriate to sanitize the 64 bit compile even if it incurred
> httpd API changes. However if there are specific security issues
> that this has brought up I am more than anxious to address them.
> Are you opposed to changing the API to fix 64 bit warnings or
> are there specific issues that I can address and continue to
> move forward rather that back out the entire patch?
I am opposed to changing the API just to mask warnings within
the implementations. In any case, these changes cannot possibly
be correct -- the API has to be changed from the bottom-up, not
top-down. It is far safer to cast module-provided data from int
up to 64 bits than it is to cast it down from 64 bit to int.
Fix mismatches of the standard library functions first, then
fix APR, then carefully change our implementation so that it works
efficiently on the right data types as provided by APR, and finally
fix the API so that modules can work. If that isn't possible, then
just live with those warnings on win64.
In any case, changes like
> + /* Cast to eliminate 64 bit warning */
> + rv = apr_file_gets(buf, (int)bufsiz, cfp);
are absolutely forbidden.
....Roy
