At 12:48 PM 2/18/2004, Ben Reser wrote:
>On Tue, Feb 17, 2004 at 01:15:12PM -0600, William A. Rowe, Jr. wrote:
>> I am against changing the default size or alignment of any data type
>> in
>> APR_0_9_BRANCH. If this [has] happened we break all binary compat.
>
>Umm we've been careful to avoid doin
On Tue, Feb 17, 2004 at 01:15:12PM -0600, William A. Rowe, Jr. wrote:
> I am against changing the default size or alignment of any data type
> in
> APR_0_9_BRANCH. If this [has] happened we break all binary compat.
Umm we've been careful to avoid doing exactly that. The point here
isn't to chang
At 03:31 AM 2/17/2004, Ben Reser wrote:
>On Wed, Feb 04, 2004 at 03:22:17PM +, Joe Orton wrote:
>> On Mon, Feb 02, 2004 at 05:19:09PM -0800, Ben Reser wrote:
>> > On Wed, Jan 28, 2004 at 04:45:26PM -0800, Ben Reser wrote:
>> > > So I guess I'll look into redoing it to use int, long or long long
On Wed, Feb 04, 2004 at 03:22:17PM +, Joe Orton wrote:
> On Mon, Feb 02, 2004 at 05:19:09PM -0800, Ben Reser wrote:
> > On Wed, Jan 28, 2004 at 04:45:26PM -0800, Ben Reser wrote:
> > > So I guess I'll look into redoing it to use int, long or long long
> > > instead.
> >
> > I found some time t
On Mon, Feb 02, 2004 at 05:19:09PM -0800, Ben Reser wrote:
> On Wed, Jan 28, 2004 at 04:45:26PM -0800, Ben Reser wrote:
> > So I guess I'll look into redoing it to use int, long or long long
> > instead.
>
> I found some time to look at this. The types I'm using now match the
> formats we were us
On Tue, Feb 03, 2004 at 04:40:38PM +, Joe Orton wrote:
> Thanks - can you make a patch relative to the APR_0_9_BRANCH branch?
Sure, here you go.
--
Ben Reser <[EMAIL PROTECTED]>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
? ran
On Mon, Feb 02, 2004 at 05:19:09PM -0800, Ben Reser wrote:
> On Wed, Jan 28, 2004 at 04:45:26PM -0800, Ben Reser wrote:
> > So I guess I'll look into redoing it to use int, long or long long
> > instead.
>
> I found some time to look at this. The types I'm using now match the
> formats we were us
On Wed, Jan 28, 2004 at 04:45:26PM -0800, Ben Reser wrote:
> So I guess I'll look into redoing it to use int, long or long long
> instead.
I found some time to look at this. The types I'm using now match the
formats we were using before. So we shouldn't have an ABI conflict. If
we do we had a b
On Thu, 2004-01-29 at 06:32, Joe Orton wrote:
> Not sure what you mean by "APR code"... it would happen if the C++
> library exposes apr_off_t in its own API:
Yes, you're right; Ben corrected me on this over IRC. Sorry to confuse
the issue.
(What I was talking about was taking some or all of the
Ben's fixed-size-apr_off_t patch is now checked in for the next 0.9.x
release, many thanks to all involved.
On Wed, Jan 28, 2004 at 06:37:10PM -0500, Greg Hudson wrote:
> On Wed, 2004-01-28 at 17:34, Joe Orton wrote:
> > One possible minor issue with this patch:
> >
> > if a C++ library based on
On Wed, Jan 28, 2004 at 10:34:41PM +, Joe Orton wrote:
> One possible minor issue with this patch:
>
> if a C++ library based on APR uses apr_off_t in its API, I believe that
> changing apr_off_t from a long to an int changes the ABI of that
> library, because of the name mangling stuff.
>
>
On Wed, 2004-01-28 at 17:34, Joe Orton wrote:
> One possible minor issue with this patch:
>
> if a C++ library based on APR uses apr_off_t in its API, I believe that
> changing apr_off_t from a long to an int changes the ABI of that
> library, because of the name mangling stuff.
To clarify, this
One possible minor issue with this patch:
if a C++ library based on APR uses apr_off_t in its API, I believe that
changing apr_off_t from a long to an int changes the ABI of that
library, because of the name mangling stuff.
I don't know of any C++ libraries based on APR, and fixing the
incompatib
On Wed, Jan 28, 2004 at 10:00:30AM -0800, Kean Johnston wrote:
> On a typical system that we are likely to care about today ... how many
> things are actually using APR that cant be (and arent being) easily
> updated? The two largest consumers of APR are Apache and SubVersion
> right? SVN is chn
That's asking for a level of ABI guarantee which I don't think APR can
provide regardless of this apr_off_t issue.
But I agree with Greg, you can address the ABI issues as you find them.
This is one that is easily addressed by APR.
Will a libapr-0.so built on RHL9 have a compatible ABI with a
lib
On Wed, 2004-01-28 at 13:00, Kean Johnston wrote:
> > That looks great: I'll commit your patch to the 0.9 branch unless there
> > are any objections. Thanks a lot for working on this issue.
> My personal opinion is that its approaching the issue the wrong way. I
> think first and foremost, we nee
That looks great: I'll commit your patch to the 0.9 branch unless there
are any objections. Thanks a lot for working on this issue.
My personal opinion is that its approaching the issue the wrong way. I
think first and foremost, we need to establish why ABI compatibility
with a 0.9 release is so
On Tue, Jan 27, 2004 at 07:33:25PM -0800, Ben Reser wrote:
> On Tue, Jan 27, 2004 at 10:32:20AM -0500, Greg Hudson wrote:
> > There is a new idea afloat, incidentally: rather than fix apr_off_t at
> > 64 bits, fix apr_off_t at the size off_t has at configuration time.
> > (There appears to be no o
On Tue, Jan 27, 2004 at 10:32:20AM -0500, Greg Hudson wrote:
> There is a new idea afloat, incidentally: rather than fix apr_off_t at
> 64 bits, fix apr_off_t at the size off_t has at configuration time.
> (There appears to be no off32_t, so that would have to be apr_int32_t on
> most 32-bit platf
On Tue, Jan 27, 2004 at 10:32:20AM -0500, Greg Hudson wrote:
> On Tue, 2004-01-27 at 05:49, Joe Orton wrote:
> > > Won't that create an ABI time bomb for platforms which have no
> > > large-file support now, but acquire it in the future?
> >
> > That's asking for a level of ABI guarantee which I d
On Fri, Jan 23, 2004 at 12:45:43PM -0500, Greg Hudson wrote:
> (Please keep me cc'd on replies, incidentally.)
>
> Joe Orton wrote:
> > I think the best way to achieve this is to define apr_off_t as
> > off64_t on such platforms, rather than unconditionally change
> > apr_off_t everywhere, and add
On Tue, 2004-01-27 at 05:49, Joe Orton wrote:
> > Won't that create an ABI time bomb for platforms which have no
> > large-file support now, but acquire it in the future?
>
> That's asking for a level of ABI guarantee which I don't think APR can
> provide regardless of this apr_off_t issue.
>
> W
(Please keep me cc'd on replies, incidentally.)
Joe Orton wrote:
> I think the best way to achieve this is to define apr_off_t as
> off64_t on such platforms, rather than unconditionally change
> apr_off_t everywhere, and add LFS support to APR: most of this work
> is already done inside #ifdef NE
On Thu, Jan 22, 2004 at 06:10:18PM -0500, Greg Hudson wrote:
> I'm going to propose fixing apr_off_t at 64 bits regardless of the
> system off_t. This is not about getting large-file support in APR,
> although that could come as a side-effect; this is about helping
> APR-using libraries to be comp
On Jan 22, 2004, at 6:10 PM, Greg Hudson wrote:
Now, the down sides:
* APR 1.0 would be incompatible with APR 0.9. If any httpd APIs use
apr_off_t (and I'm pretty sure that some do), then httpd 2.x
becomes stuck at APR 0.9. Similarly, if any svn 1.0 APIs use
apr_off_t (currently a m
I'm going to propose fixing apr_off_t at 64 bits regardless of the
system off_t. This is not about getting large-file support in APR,
although that could come as a side-effect; this is about helping
APR-using libraries to be compatible with two different universes of
libraries, and making APR itse
26 matches
Mail list logo
