apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39463] - Sendfile broken in 2.2.2 on Solaris 10 when using Server parsed html includes
Date Wed, 08 Nov 2006 13:21:54 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39463>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39463





------- Additional Comments From dbb@st-andrews.ac.uk  2006-11-08 05:21 -------

As an update, the engineer disagrees that Solaris should ignore the top 32 bits
as (I'm paraphrasing here) you are effectively casting as the wrong type, the
kernel would have to selectively ignore data passed in on the basis of incorrect
coding.  
The apache code requests the use of the sendfilevec64 struct which has the type
for the offset field svf_off defined in the header file as off64_t (a long long,
see <sys/types.h>). When the correct type is used with the Sun compiler, the
results are as expected. 

I'll attach the code to demonstrate this to the case.

Use of the type "apr_off_t" or "long" which implies a signed value, hence sign
extension is performed.
Use of the correct type "off64_t" with gcc still generates a sign-extended
value. (This may be a fault/feature of gcc)

The workaround works but with the proviso that unsigned long != off64_t

Is it worth bringing this up with the GCC folks so you can put the correct type
into sendfilev.c ?

Thanks for all the help.

   Duncan



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mime
View raw message