apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: remaining issues prior to 1.0?
Date Wed, 03 Sep 2003 04:22:21 GMT
--On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman <stas@stason.org> 

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

> 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.

> 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.

> 3) there is no apr_file_tell
> http://marc.theaimsgroup.com/?t=100748110600004&r=1&w=2

Cliff and I just talked about how you'd solve this in #apr.  He's writing a 
reply now.  -- justin

View raw message