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.
