apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [PATCH] WIN64: apr_pools.c
Date Thu, 30 Sep 2004 14:12:10 GMT
On Wed, 29 Sep 2004 23:00:52 +0100, Joe Orton <jorton@redhat.com> wrote:
> On Wed, Sep 29, 2004 at 05:35:34PM -0400, Allan Edwards wrote:
> > In order to eliminate the following warnings for Win64 builds the
> > appended patch is needed. However this changes fields in the apr_memnode_t
> > structure in apr/include/apr_allocator.h
> >
> > Seems that this strucure really should be private and moved along
> > with struct apr_allocator_t to include/arch/unix/apr_arch_allocator.h
> > but either moving it or changing it may be construed as changing
> > the 1.0 API. Personally I don't think so but if anyone thinks
> > otherwise let's discuss.
> 
> It is part of the API, it can't be changed like this in 1.x.  You can't
> use the apr_allocator_* API without using the apr_memnode_t structure,
> so I don't see how it could be made private either.

so 64-bit APR can't handle very large memory objects (which isn't
something I'll lose sleep over any time soon)...

something obviously needs to be done with this type of issue to avoid
the multitude of compile warnings and also fail any request to handle
larger (e.g., maybe an allocation function has a parameter which can
hold more than uint32, but since allocator can't store that much the
request must be failed)

but apr_allocator_max_free_set() has no retcode, so it has to be documented that
it can't handle more than will fit in 32-bit unsigned int, and on
entry it needs to copy with truncation (and no warning) the apr_size_t
parameter into a local 32-bit variable

Mime
View raw message