From: "Stas Bekman" <[EMAIL PROTECTED]> 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. Bill
