apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: httpd 2.2.8 segfaults
Date Fri, 22 Feb 2008 18:40:07 GMT
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.

Mime
View raw message