You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joe Orton <jo...@redhat.com> on 2008/02/22 19:36:05 UTC
Re: httpd 2.2.8 segfaults
CC'ing dev@apr since the code in question is in APR.
On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group wrote:
> > On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
> > > + /*
> > > + * Try to reduce the following casting mess: We know that point will be
> > > + * larger equal 0 now and forever and thus that point (apr_off_t) and
> > > + * apr_size_t will fit into apr_uint64_t in any case.
> > > + */
> >
> > Do we really know that? Is that confirmed at configure
> > time?
>
> Do we have any integer on any platform that we support that is larger
> as apr_uint64_t / apr_int64_t?
> I always thought that they are the largest and that on no platform
> we have any integers with more than 64 bit.
APR doesn't support any platform where sizeof(apr_off_t) > 8, that is
correct.
joe
Re: httpd 2.2.8 segfaults
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Feb 22, 2008, at 5:21 PM, Ruediger Pluem wrote:
>
>
> On 02/22/2008 07:40 PM, William A. Rowe, Jr. wrote:
>> Joe Orton wrote:
>>> CC'ing dev@apr since the code in question is in APR.
>>>
>>> On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group
>>> wrote:
>>>>> On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
>>>>>> + /*
>>>>>> + * Try to reduce the following casting mess: We know that
>>>>>> point will be
>>>>>> + * larger equal 0 now and forever and thus that point
>>>>>> (apr_off_t) and
>>>>>> + * apr_size_t will fit into apr_uint64_t in any case.
>>>>>> + */
>>>>> Do we really know that? Is that confirmed at configure
>>>>> time?
>>>> Do we have any integer on any platform that we support that is
>>>> larger
>>>> as apr_uint64_t / apr_int64_t?
>>>> I always thought that they are the largest and that on no platform
>>>> we have any integers with more than 64 bit.
>>>
>>> APR doesn't support any platform where sizeof(apr_off_t) > 8, that
>>> is correct.
>> Don't we know for a fact that apr_off_t >= apr_size_t on all
>> platforms,
>> today?
>
> Do we have 32 bit platforms without LFS?
Why are we asking these questions? If we need to ask or
ensure something, that is what configure is there for :) :)
Re: httpd 2.2.8 segfaults
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Feb 22, 2008, at 5:21 PM, Ruediger Pluem wrote:
>
>
> On 02/22/2008 07:40 PM, William A. Rowe, Jr. wrote:
>> Joe Orton wrote:
>>> CC'ing dev@apr since the code in question is in APR.
>>>
>>> On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group
>>> wrote:
>>>>> On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
>>>>>> + /*
>>>>>> + * Try to reduce the following casting mess: We know that
>>>>>> point will be
>>>>>> + * larger equal 0 now and forever and thus that point
>>>>>> (apr_off_t) and
>>>>>> + * apr_size_t will fit into apr_uint64_t in any case.
>>>>>> + */
>>>>> Do we really know that? Is that confirmed at configure
>>>>> time?
>>>> Do we have any integer on any platform that we support that is
>>>> larger
>>>> as apr_uint64_t / apr_int64_t?
>>>> I always thought that they are the largest and that on no platform
>>>> we have any integers with more than 64 bit.
>>>
>>> APR doesn't support any platform where sizeof(apr_off_t) > 8, that
>>> is correct.
>> Don't we know for a fact that apr_off_t >= apr_size_t on all
>> platforms,
>> today?
>
> Do we have 32 bit platforms without LFS?
Why are we asking these questions? If we need to ask or
ensure something, that is what configure is there for :) :)
Re: httpd 2.2.8 segfaults
Posted by Ruediger Pluem <rp...@apache.org>.
On 02/22/2008 07:40 PM, William A. Rowe, Jr. wrote:
> Joe Orton wrote:
>> CC'ing dev@apr since the code in question is in APR.
>>
>> On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group wrote:
>>>> On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
>>>>> + /*
>>>>> + * Try to reduce the following casting mess: We know that
>>>>> point will be
>>>>> + * larger equal 0 now and forever and thus that point
>>>>> (apr_off_t) and
>>>>> + * apr_size_t will fit into apr_uint64_t in any case.
>>>>> + */
>>>> Do we really know that? Is that confirmed at configure
>>>> time?
>>> Do we have any integer on any platform that we support that is larger
>>> as apr_uint64_t / apr_int64_t?
>>> I always thought that they are the largest and that on no platform
>>> we have any integers with more than 64 bit.
>>
>> APR doesn't support any platform where sizeof(apr_off_t) > 8, that is
>> correct.
>
> Don't we know for a fact that apr_off_t >= apr_size_t on all platforms,
> today?
Do we have 32 bit platforms without LFS? In this case I would assume
that apr_size_t is an unsigned 32 bit integer whereas apr_off_t is a signed
32 bit integer. So this assumption would not be true there.
Even if do not think that it would really hurt us in practice, but what about
64 bit platforms? Don't they use a 64 bit signed integer for apr_off_t and
a 64 unsigned one for apr_size_t?
>
> I can't see how apr supporting only file offsets smaller than available
> memory would ever be desirable.
I think this is not a matter of APR, but a matter of the original definitions
of off_t and size_t like in my possible correct examples above :-).
Regards
Rüdiger
Re: httpd 2.2.8 segfaults
Posted by Ruediger Pluem <rp...@apache.org>.
On 02/22/2008 07:40 PM, William A. Rowe, Jr. wrote:
> Joe Orton wrote:
>> CC'ing dev@apr since the code in question is in APR.
>>
>> On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group wrote:
>>>> On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
>>>>> + /*
>>>>> + * Try to reduce the following casting mess: We know that
>>>>> point will be
>>>>> + * larger equal 0 now and forever and thus that point
>>>>> (apr_off_t) and
>>>>> + * apr_size_t will fit into apr_uint64_t in any case.
>>>>> + */
>>>> Do we really know that? Is that confirmed at configure
>>>> time?
>>> Do we have any integer on any platform that we support that is larger
>>> as apr_uint64_t / apr_int64_t?
>>> I always thought that they are the largest and that on no platform
>>> we have any integers with more than 64 bit.
>>
>> APR doesn't support any platform where sizeof(apr_off_t) > 8, that is
>> correct.
>
> Don't we know for a fact that apr_off_t >= apr_size_t on all platforms,
> today?
Do we have 32 bit platforms without LFS? In this case I would assume
that apr_size_t is an unsigned 32 bit integer whereas apr_off_t is a signed
32 bit integer. So this assumption would not be true there.
Even if do not think that it would really hurt us in practice, but what about
64 bit platforms? Don't they use a 64 bit signed integer for apr_off_t and
a 64 unsigned one for apr_size_t?
>
> I can't see how apr supporting only file offsets smaller than available
> memory would ever be desirable.
I think this is not a matter of APR, but a matter of the original definitions
of off_t and size_t like in my possible correct examples above :-).
Regards
Rüdiger
Re: httpd 2.2.8 segfaults
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> CC'ing dev@apr since the code in question is in APR.
>
> On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group wrote:
>>> On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
>>>> + /*
>>>> + * Try to reduce the following casting mess: We know that point will be
>>>> + * larger equal 0 now and forever and thus that point (apr_off_t) and
>>>> + * apr_size_t will fit into apr_uint64_t in any case.
>>>> + */
>>> Do we really know that? Is that confirmed at configure
>>> time?
>> Do we have any integer on any platform that we support that is larger
>> as apr_uint64_t / apr_int64_t?
>> I always thought that they are the largest and that on no platform
>> we have any integers with more than 64 bit.
>
> APR doesn't support any platform where sizeof(apr_off_t) > 8, that is
> correct.
Don't we know for a fact that apr_off_t >= apr_size_t on all platforms,
today?
I can't see how apr supporting only file offsets smaller than available
memory would ever be desirable.
Re: httpd 2.2.8 segfaults
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> CC'ing dev@apr since the code in question is in APR.
>
> On Fri, Feb 22, 2008 at 05:45:53PM +0100, Plüm, Rüdiger, VF-Group wrote:
>>> On Feb 22, 2008, at 9:27 AM, Plüm, Rüdiger, VF-Group wrote:
>>>> + /*
>>>> + * Try to reduce the following casting mess: We know that point will be
>>>> + * larger equal 0 now and forever and thus that point (apr_off_t) and
>>>> + * apr_size_t will fit into apr_uint64_t in any case.
>>>> + */
>>> Do we really know that? Is that confirmed at configure
>>> time?
>> Do we have any integer on any platform that we support that is larger
>> as apr_uint64_t / apr_int64_t?
>> I always thought that they are the largest and that on no platform
>> we have any integers with more than 64 bit.
>
> APR doesn't support any platform where sizeof(apr_off_t) > 8, that is
> correct.
Don't we know for a fact that apr_off_t >= apr_size_t on all platforms,
today?
I can't see how apr supporting only file offsets smaller than available
memory would ever be desirable.