httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: cvs commit: httpd-2.0/server core.c protocol.c request.c scoreboard.c uti...
Date Sat, 23 Oct 2004 00:49:29 GMT

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, 
fielding@gbiv.com 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
> 
> 


Mime
View raw message