On Wed, 29 Sep 2004 23:00:52 +0100, Joe Orton <[EMAIL PROTECTED]> 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
