apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: remaining issues prior to 1.0?
Date Wed, 03 Sep 2003 05:04:52 GMT
Justin Erenkrantz wrote:
> --On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman 
> <stas@stason.org> wrote:
> 
>> Other outstanding issues that IMHO can/should be fixed in 1.0.
>>
>> Configure issues:
>>
>> 1) dealing with APR_HAS_LARGE_FILES on linux
>> http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
>> Currently it's just disabled, even when available.
>> the whole thread is here:
>> http://marc.theaimsgroup.com/?t=105271796700002&r=1&w=2
> 
> 
> IMHO, this isn't a 1.0 showstopper.  Someone who has a Linux box can 
> step up and add the right configure logic.  No API change is required 
> here.  We don't need to hold up 1.0 because no Linux developers care to 
> fix it.  (I don't have access to Linux boxes with working sendfile64, so 
> I'm of zero help here.)

Isn't here anybody who understands the ./configure logic on linux?

>> 1) apr_strfsize is limited to the availability of LARGEFILES support,
>> whereas it's advertised as a general purpose function and has nothing 
>> to do
>> with the filesize. The thread that wasn't finished is here:
>> http://marc.theaimsgroup.com/?t=101232935300002&r=1&w=2
> 
> 
> I'm not understanding why this is related to LARGEFILES at all?  Do you 
> mean that you'd want this to work with 64-bit integers regardless of 
> apr_off_t's size?  Don't see that as 'must-fix' before 1.0.

Yes. I suggested that the API name will be changes to reflect the reality.

>> 2) s/ap_ht_time/apr_date_format_http/g
>> http://marc.theaimsgroup.com/?t=101232878000006&r=1&w=2
>> Bill says it's a good API change (move into apr):
>> http://marc.theaimsgroup.com/?l=apr-dev&m=101232960930699&w=2
> 
> 
> According to the version rules, functions can be added at any time.  
> Again, not a 1.0 showstopper.

Alright, but why not doing this simple change. It doesn't take longer than 
running s/// and adjusting the header files.


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message