You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ben Reser <be...@reser.org> on 2004/02/03 02:19:09 UTC
Re: Solving the off_t problem in APR 1.0
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 bug with the formats already.
The one case where this may exist would be 64-bit archs with 64-bit
off_t's. These platforms could use long long or long for the off_t.
They might choose differently than we have for apr_int64_t. I don't
know of any other way to deal with this than what was already done with
the LFS platforms that use long for off_t. We'll simply have to detect
these platforms one by one and apply exceptions for them.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
Re: Solving the off_t problem in APR 1.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 doing exactly that. The point here
>isn't to change size of the type. It's to fix it at compile time rather
>than at build time. The last patch sent most definitely does that
>without altering size of anytime and additionally without altering the
>type which would change the name mangling in C++.
Excellent - I will review on a few different unix platforms w.r.t. apr 9.4
v.s. head.
>> Good fix for APR 1.0 along with all the other problematic design
>> decisions
>> we made in 0.9's twisty and winding road. +1 for 1.0
>
>There are potentially cleaner ways to fix this in 1.0. This is a
>temporary work around for a problem.
Ack.
Re: Solving the off_t problem in APR 1.0
Posted by Ben Reser <be...@reser.org>.
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 change size of the type. It's to fix it at compile time rather
than at build time. The last patch sent most definitely does that
without altering size of anytime and additionally without altering the
type which would change the name mangling in C++.
> Good fix for APR 1.0 along with all the other problematic design
> decisions
> we made in 0.9's twisty and winding road. +1 for 1.0
There are potentially cleaner ways to fix this in 1.0. This is a
temporary work around for a problem.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
Re: Solving the off_t problem in APR 1.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:31 AM 2/17/2004, Ben Reser wrote:
>On Wed, Feb 04, 2004 at 03:22:17PM +0000, 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 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 bug with the formats already.
>> >
>> > The one case where this may exist would be 64-bit archs with 64-bit
>> > off_t's. These platforms could use long long or long for the off_t.
>> > They might choose differently than we have for apr_int64_t. I don't
>> > know of any other way to deal with this than what was already done with
>> > the LFS platforms that use long for off_t. We'll simply have to detect
>> > these platforms one by one and apply exceptions for them.
>>
>> Alternatively, apr_off_t could be set to an integer type only on
>> platforms where sizeof(int)==4: for real LP64 platforms (and those
>> sizeof(int)==2 platforms which APR really doesn't build on anyway), just
>> leave apr_off_t defined to off_t.
>>
>> This would be perhaps be simpler...
>
>I'm going to try and find time to look at this alternative solution
>tomorrow. I want to have this "closed" in APR before we put out
>Subversion 1.0.
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.
Good fix for APR 1.0 along with all the other problematic design decisions
we made in 0.9's twisty and winding road. +1 for 1.0
Bill
Re: Solving the off_t problem in APR 1.0
Posted by Ben Reser <be...@reser.org>.
On Wed, Feb 04, 2004 at 03:22:17PM +0000, 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 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 bug with the formats already.
> >
> > The one case where this may exist would be 64-bit archs with 64-bit
> > off_t's. These platforms could use long long or long for the off_t.
> > They might choose differently than we have for apr_int64_t. I don't
> > know of any other way to deal with this than what was already done with
> > the LFS platforms that use long for off_t. We'll simply have to detect
> > these platforms one by one and apply exceptions for them.
>
> Alternatively, apr_off_t could be set to an integer type only on
> platforms where sizeof(int)==4: for real LP64 platforms (and those
> sizeof(int)==2 platforms which APR really doesn't build on anyway), just
> leave apr_off_t defined to off_t.
>
> This would be perhaps be simpler...
I'm going to try and find time to look at this alternative solution
tomorrow. I want to have this "closed" in APR before we put out
Subversion 1.0.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
Re: Solving the off_t problem in APR 1.0
Posted by Joe Orton <jo...@manyfish.co.uk>.
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 using before. So we shouldn't have an ABI conflict. If
> we do we had a bug with the formats already.
>
> The one case where this may exist would be 64-bit archs with 64-bit
> off_t's. These platforms could use long long or long for the off_t.
> They might choose differently than we have for apr_int64_t. I don't
> know of any other way to deal with this than what was already done with
> the LFS platforms that use long for off_t. We'll simply have to detect
> these platforms one by one and apply exceptions for them.
Alternatively, apr_off_t could be set to an integer type only on
platforms where sizeof(int)==4: for real LP64 platforms (and those
sizeof(int)==2 platforms which APR really doesn't build on anyway), just
leave apr_off_t defined to off_t.
This would be perhaps be simpler...
joe
Re: Solving the off_t problem in APR 1.0
Posted by Ben Reser <be...@reser.org>.
On Tue, Feb 03, 2004 at 04:40:38PM +0000, Joe Orton wrote:
> Thanks - can you make a patch relative to the APR_0_9_BRANCH branch?
Sure, here you go.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
Re: Solving the off_t problem in APR 1.0
Posted by Joe Orton <jo...@redhat.com>.
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 using before. So we shouldn't have an ABI conflict. If
> we do we had a bug with the formats already.
Thanks - can you make a patch relative to the APR_0_9_BRANCH branch?
joe