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 Wed, 30 Jan 2002 06:15:01 GMT
From: "Stas Bekman" <stas@stason.org>
Sent: Tuesday, January 29, 2002 11:34 PM

> William A. Rowe, Jr. wrote:
> > fsize is filesize plain and simple :)  So rename it appropriately as I pointed
> > out below.
> really? I read it as string_format_size, the same as strftime stands for 
> string_format_time.
> Now I understand the source of my confusion, but boy, this is so not 
> obvious. I still think apr_file_strsize is a much better name.


Sorry for being a DPIA... yes, string_format_size makes sense too now that you
point out that flavor to me.  In any case, what is 'size' anyway?  fsize sure
implies file_size to me.  Your suggested symbol name would be great, except 
we've decided it doesn't map 'file sizes', but an shorthand rounded binary 
value.  I don't see a man page to strfsize, so I guess that rulebook isn't
written anywhere.

> >>>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.
> no prob. what should be the name then? apr_str_fmt_size

Good question...

> since APR keeps on growing it'd be very nice to try hard to maintain 
> "virtual" namespaces for most of the functions so you always have two 
> top namespace levels before you reach the function name.

Yes, agreed.  I love what the modperl team has done to instill a little discipline
into the apr project :)  But you have a slew to deal with [c.f. 'strnatcmp'.]

> so apr_file_ is the namespace for files related functions, therefore 
> with common sense applied, apr_strfsize should be there, like in 
> apr_file_strsize.

Not if it doesn't take apr_off_t.  This is no longer a 'file' function, right :-?

> If we are talking about general purpose string manipulation function it 
> should probably live in apr_str_ namespace, like apr_str_fmt_size.

WTF is size?  size_t?  file size (off_t)?  Shoe size :-?

We need to find a 'better' name that is a bit more descriptive.  Drop the 
adjective 'size' and the noun 'file'.  There is binary and decimal metric 
shorthand.  That's all we are promising here, take a number and turn it
into a shorthand string.  lltoa() gone amuck :)

One observation... clib strfoo functions take strings as their args.  We aren't
passing a string.  Yes, strftime is an anomily.  apr_str_fmt_time makes more
sense, as would apr_time_string_format() (and apr_time_string_parse).

However, I have one more thought [there he goes again...]  This is no longer a
portability fn whatsoever.  Really aught to move to apr_util.  So should the
strnatcmp and a few others.

The only reason for str functions to live in apr, is that they are horribly
dirty to implement (apr_snprintf), or required by apr.  Someone can point out
my brain is going on overtime, and it makes no sense to have 'two string libs'.
But AFAICT, things like strnatcmp really are not portability concerns and really
aren't needed by apr at all.

Finally, with way too many different thoughts already spread out here, I'll
close by pointing out that the fn name that made sense to _Apache_ isn't going
to always make the most sense in the APR project.  Just food for thought.


View raw message