William A. Rowe, Jr. wrote:


So apr_strfsize is not a general purpose functions anymore, since it's tied to files. Which means that we again need to reimplement it, if we want to have a general purpose function for formatting sizes and handle big files without imposing a LARGEFILES requirement.


No, it's an apr function. But please consider the following;

Can Apache handle the file you've just listed as 24KB instead of 4GB+24KB?

No, of course not.  Nor could any program built with APR.

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.


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 :)


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?


BTW - the veto of changing the type of the dirent .size member from
apr_off_t still stands.

Ok

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/



Reply via email to