apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: httpd 2.2.8 segfaults
Date Mon, 25 Feb 2008 13:44:26 GMT

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


Mime
View raw message