You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2002/01/28 07:26:21 UTC
Apache::Util::size_string issues
Doug MacEachern wrote:
> On Fri, 25 Jan 2002, Stas Bekman wrote:
>>- size_string (has nothing to do with Apache
>> or should it stay in Apache::Util?)
>>
>
> it used to be a string version of ap_send_size(), which no longer exists
> in favor of the new apr_strfsize() function. we should use that in 2.0
> and add a compat wrapper for Apache::Util::size_string.
OK, how about this then:
static MP_INLINE
SV *mpxs_Apache__Util_size_string(pTHX_ apr_off_t size)
{
char buff[5];
apr_strfsize(size, buff);
return newSVpvn(buff, 4);
}
we want it to be perlish, right?
there is a problem with apr_off_t since we typedef it as IV, therefore
if you try:
Apache::Util::size_string(42_000_000_000);
it looses data when converting from NV or PV to IV. Which means that we
can use this function only up to 1G numbers or so. Doesn't sound good.
Also apr_strfsize is in the APR::Strings module in the map file. Should
we have APR::Strings::strfsize instead of Apache__Util_size_string.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Apache::Util::size_string issues
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Tue, 29 Jan 2002, Stas Bekman wrote:
>
>
>>Since we have a potentially growing number of Util functions, may be
>>it's better not to throw all the functions into one namespace? So in
>>this case we could make something like Apache::StringUtil or
>>Apache::UtilString?
>>
>>Because if for example you look at APR::Table, it's a util too.
>>
>
> APR::Table all live in the apr_table_ namespace. apr_strfsize doesn't
> really have a C namespace beyond apr_, the closest would be APR::String.
> probably should be apr_string_format_size(), but i'm tired of renaming apr
> functions.
;(
>>In any case I'll go with Apache::Util::format_size and later we can
>>change it. Sounds OK?
>>
>
> APR::
of course :)
> it should be APR::Util::strfsize or APR::String::format_size.
OK, I'll go with APR::String::format_size
Thanks Doug!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Apache::Util::size_string issues
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 29 Jan 2002, Stas Bekman wrote:
> Since we have a potentially growing number of Util functions, may be
> it's better not to throw all the functions into one namespace? So in
> this case we could make something like Apache::StringUtil or
> Apache::UtilString?
>
> Because if for example you look at APR::Table, it's a util too.
APR::Table all live in the apr_table_ namespace. apr_strfsize doesn't
really have a C namespace beyond apr_, the closest would be APR::String.
probably should be apr_string_format_size(), but i'm tired of renaming apr
functions.
> In any case I'll go with Apache::Util::format_size and later we can
> change it. Sounds OK?
APR::
it should be APR::Util::strfsize or APR::String::format_size.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Apache::Util::size_string issues
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Tue, 29 Jan 2002, Stas Bekman wrote:
>
>>like this?
>>
>
> yeah, but i'm not sure it's worth it for such a small string. in fact, i
> think it is a loss, see comment in sv.c:
> /*
> * Check to see if we can just swipe the string. If so, it's a
> * possible small lose on short strings, but a big win on long ones.
> * It might even be a win on short strings if SvPVX(dstr)
> * has to be allocated and SvPVX(sstr) has to be freed.
> */
>
> probably best to stick with your original.
ok
>>>>Also apr_strfsize is in the APR::Strings module in the map file. Should
>>>>we have APR::Strings::strfsize instead of Apache__Util_size_string.
>>>>
>
> that is probably the right place. but Apache::String::format_size has a
> better ring to it. either that or just group it with APR::Util (as
> APR::Util::strfsize), where the current APR::Lib functions are supposed to
> move to.
Since we have a potentially growing number of Util functions, may be
it's better not to throw all the functions into one namespace? So in
this case we could make something like Apache::StringUtil or
Apache::UtilString?
Because if for example you look at APR::Table, it's a util too.
In any case I'll go with Apache::Util::format_size and later we can
change it. Sounds OK?
Apache::Util::size_string as a wrapper.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Apache::Util::size_string issues
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 29 Jan 2002, Stas Bekman wrote:
> like this?
yeah, but i'm not sure it's worth it for such a small string. in fact, i
think it is a loss, see comment in sv.c:
/*
* Check to see if we can just swipe the string. If so, it's a
* possible small lose on short strings, but a big win on long ones.
* It might even be a win on short strings if SvPVX(dstr)
* has to be allocated and SvPVX(sstr) has to be freed.
*/
probably best to stick with your original.
> you mean, apr_strfsize, not apr_strftime
yup.
> OK, will ask.
might be worth checking what mod_autoindex outputs for a file of size
greater than what apr_off_t can hold too.
> what about this:
>
> >>Also apr_strfsize is in the APR::Strings module in the map file. Should
> >>we have APR::Strings::strfsize instead of Apache__Util_size_string.
that is probably the right place. but Apache::String::format_size has a
better ring to it. either that or just group it with APR::Util (as
APR::Util::strfsize), where the current APR::Lib functions are supposed to
move to.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Apache::Util::size_string issues
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Mon, 28 Jan 2002, Stas Bekman wrote:
>
>
>>static MP_INLINE
>>SV *mpxs_Apache__Util_size_string(pTHX_ apr_off_t size)
>>{
>> char buff[5];
>>
>> apr_strfsize(size, buff);
>>
>> return newSVpvn(buff, 4);
>>}
>>
>
> that'd be fine. i'd probably use mpxs_set_targ instead, but that can be
> later.
like this?
static MP_INLINE void mpxs_apr_strfsize(pTHX_ SV *sv, SV *arg)
{
apr_off_t size = mp_xs_sv2_apr_off_t(arg);
char *ptr;
mpxs_sv_grow(sv, 5);
apr_strfsize(size, ptr);
mpxs_sv_cur_set(sv, strlen(ptr)); /*XXX*/
}
static XS(MPXS_apr_strfsize)
{
dXSARGS;
mpxs_usage_items_1("size");
mpxs_set_targ(mpxs_apr_strfsize, ST(0));
}
>>we want it to be perlish, right?
>>
>>there is a problem with apr_off_t since we typedef it as IV, therefore
>>if you try:
>>
>> Apache::Util::size_string(42_000_000_000);
>>
>>it looses data when converting from NV or PV to IV. Which means that we
>>can use this function only up to 1G numbers or so. Doesn't sound good.
>>
>
> normally off_t is the same size as IV, you'd have to compile apache with
> largefile flags to make it bigger. might be better to change apr_strftime
> to use a type that can always hold a bigger number.
you mean, apr_strfsize, not apr_strftime
OK, will ask.
what about this:
>>Also apr_strfsize is in the APR::Strings module in the map file. Should
>>we have APR::Strings::strfsize instead of Apache__Util_size_string.
>>
--
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Apache::Util::size_string issues
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 28 Jan 2002, Stas Bekman wrote:
> static MP_INLINE
> SV *mpxs_Apache__Util_size_string(pTHX_ apr_off_t size)
> {
> char buff[5];
>
> apr_strfsize(size, buff);
>
> return newSVpvn(buff, 4);
> }
that'd be fine. i'd probably use mpxs_set_targ instead, but that can be
later.
> we want it to be perlish, right?
>
> there is a problem with apr_off_t since we typedef it as IV, therefore
> if you try:
>
> Apache::Util::size_string(42_000_000_000);
>
> it looses data when converting from NV or PV to IV. Which means that we
> can use this function only up to 1G numbers or so. Doesn't sound good.
>
> Also apr_strfsize is in the APR::Strings module in the map file. Should
> we have APR::Strings::strfsize instead of Apache__Util_size_string.
normally off_t is the same size as IV, you'd have to compile apache with
largefile flags to make it bigger. might be better to change apr_strftime
to use a type that can always hold a bigger number.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org