apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: httpd 2.2.8 segfaults
Date Fri, 22 Feb 2008 22:21:33 GMT


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



Mime
View raw message