apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: apr_strfsize cannot handle sizes bigger than a few MiBs without largefiles support
Date Tue, 29 Jan 2002 19:54:27 GMT
From: "Stas Bekman" <stas@stason.org>
Sent: Tuesday, January 29, 2002 1:18 PM

> William A. Rowe, Jr. wrote:
> > I'd comprimize, if you like.  If we determine that this .size member 
> > is > MAX_APR_OFF_T, we set the size to MAX_APR_OFF_T.  In apr_strfsize,
> > we replace that value MAX_APR_OFF_T with some hardcode, such as "Huge ",
> > so folks don't go downloading it.
> If I understand correctly this cannot happen, you have to cast the 
> argument to apr_off_t to get it accepted by the function, so it'll 
> overflow during the casting.

ergo if (foo.size != (apr_off_t)foo.size) finfo.size = APR_MAX_OFF_T 
(now to get that actually defined :)

> > If the filesystem doesn't handle it, I fail to see what benefit we get from
> > displaying it.
> But that's not the point. My point was that I cannot see from the name 
> strfsize that this function is tied to filesystem limits. why not call 
> it apr_file_strfsize? And let apr_strfsize accept bigger values without 
> any relation to filesystem limits.
> e.g. I want to use strfsize to count money :)

fsize is filesize plain and simple :)  So rename it appropriately as I pointed
out below.

> > Unless you want to make apr_strfsize into something more generic, such as
> > apr_format_brief_size_binary(), taking the hugest int we can pass it, and 
> > returning a binary metric NNNNm where m is a magnitude.  There wouldn't
> > be any harm in that, someone could extend it to apr_format_brief_size_metric()
> > for true decimal representations.  But apr_strfsize sure sounds like a 
> > filesystem API here :)
> why stopping at int?

Exactly, apr_int64_t sounds reasonable.  If you want an implementation that takes
a double, I'd ask that you make that a second function.


View raw message