On Wed, Apr 17, 2024 at 9:36 AM Graham Leggett via dev <dev@apr.apache.org> wrote: > > On 17 Apr 2024, at 08:12, Ruediger Pluem <rpl...@apache.org> wrote: > > >> I need some advice on handling Windows 32 bit. apr_int64_t for size is too > >> big, and tests are failing. > >> > >> Technically apr_ssize_t is the right size, but the definition of ssize_t > >> is [-1, SSIZE_MAX]. I need a signed very big number. Given we define > >> apr_ssize_t, is it ok to use apr_ssize_t anyway? > > > > How about off_t / apr_off_t instead? > > Perfect, will fix.
Does it work on 32bit systems since apr_off_t is always 64bitin in apr (IIRC)? I think the right type is apr_size_t because a buffer length just can't be negative. That'd also avoid signed integers arithmetic games like: +APR_DECLARE(apr_size_t) apr_buffer_len(const apr_buffer_t *buf) +{ + if (buf->size < 0) { + return (apr_size_t)((-buf->size) - 1); + } + else { + return (apr_size_t)buf->size; + } +} If you want a bit for string vs non-string buffers just limit the size to SIZE_MAX/2 and use the high bit of an apr_size_t. The user can't use buf->size directly still and must use apr_buffer_len() but it's no different from the current implementation. Likewise for the "apr_ssize_t len" parameter of apr_buffer_str_set() and apr_buffer_str_make(), passing an sise_t/strlen() is just undefined behaviour in C so it does not really help the user. With apr_size_t one could pass APR_BUFFER_STRING for a nul-terminated string and we could check the SIZE_MAX/2 limit there still. Regards; Yann. PS: we have the very problem in the apr_encode/apr_escape interfaces.