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=28898>. 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=28898 Large file support (> 4GB) for platforms w/ 32-bit size_t and 64-bit off_t [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Large file support (> 2GB) |Large file support (> 4GB) |for platforms w/ 32-bit |for platforms w/ 32-bit |size_t and 64-bit off_t |size_t and 64-bit off_t ------- Additional Comments From [EMAIL PROTECTED] 2004-05-16 15:37 ------- > Well, since off_t is signed any size >2Gb would fail, if at all... > it works the same here for me using >4Gb sizes too The problem is sizeof(apr_off_t) > sizeof(apr_size_t) in those platforms while there are many places where apr_off_t objects are computed against apr_size_t objects. We already have learned that forcibily making apr_size_t 64-bit off-t fixes the problem (in some platforms). Oh, I have chenged the summery from "2GB" to "4GB" to be more precise. > it would be great if you could debug it Yikes. I know HOW it went wrong but WHERE to fix is another problem. Since it is size-related, that may even lead to changes in *.h, meaning API changes and that'way too much for me. > i.e. work out if apr_stat() is determining the size correctly, > and work on up... That's not the only problem. Anywhere apr_off_t is used in conjunction w/ apr_size_t are vulnerable. i.e apr_bucket_read(). Dan the Apache *User* (and love to stay that way) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
