Re: svn commit: r1917047 - in /apr/apr/trunk: CHANGES buffer/ buffer/apr_buffer.c build.conf include/apr_buffer.h test/Makefile.in test/Makefile.win test/NWGNUaprtest test/abts_tests.h test/testbuffer.c test/testutil.h

On Wed, Apr 17, 2024 at 9:36 AM Graham Leggett via dev
<[email protected]> wrote:
>
> On 17 Apr 2024, at 08:12, Ruediger Pluem <[email protected]> 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.