You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2004/05/16 17:37:12 UTC
DO NOT REPLY [Bug 28898] -
Large file support (> 4GB) for platforms w/ 32-bit size_t and 64-bit off_t
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
dankogai@dan.co.jp 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 dankogai@dan.co.jp 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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org