Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-22 Thread Graham Leggett via dev
On 18 Apr 2024, at 17:07, Yann Ylavic wrote: > If so maybe: > > typedef struct > { >union { >char *str; >void *mem; >} d; > #if APR_SIZEOF_VOIDP == 8 > # define APR_BUFFER_SIZE_WIDTH 63 > #else > # define APR_BUFFER_SIZE_WIDTH 31 > #endif > apr_size_t

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Yann Ylavic
On Thu, Apr 18, 2024 at 3:58 PM Graham Leggett wrote: > > On 18 Apr 2024, at 13:15, Yann Ylavic wrote: > >> But let me plead again for a much simpler ->size of type apr_size_t, >> checked against APR_BUFFER_MAX=APR_SIZE_MAX/2 wherever an apr_buffer_t >> is initialized, using the high bit of

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Graham Leggett via dev
On 18 Apr 2024, at 15:57, Yann Ylavic wrote: >> could be: >> APR_DECLARE(apr_status_t) apr_buffer_str_set(apr_buffer_t *buf, >> char *str, apr_size_t len) >> { >>if (len == APR_BUFFER_STRING) { >>len = str ? strlen(str) : 0; >>} >>

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Yann Ylavic
On Thu, Apr 18, 2024 at 4:41 PM Yann Ylavic wrote: > > could be: > APR_DECLARE(apr_status_t) apr_buffer_str_set(apr_buffer_t *buf, > char *str, apr_size_t len) > { > if (len == APR_BUFFER_STRING) { > len = str ? strlen(str) : 0; > } >

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Yann Ylavic
On Thu, Apr 18, 2024 at 3:58 PM Graham Leggett wrote: > > On 18 Apr 2024, at 13:15, Yann Ylavic wrote: > >> Indeed at least APR_BUFFER_MAX and buf->size of should be of the same >> signedness. > > > APR_BUFFER_MAX represents the size limit visible outside the API. This is > always positive. I

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Graham Leggett via dev
On 18 Apr 2024, at 13:15, Yann Ylavic wrote: > Indeed at least APR_BUFFER_MAX and buf->size of should be of the same > signedness. APR_BUFFER_MAX represents the size limit visible outside the API. This is always positive. buf->size is an internal implementation detail. This is invisible. The

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Graham Leggett via dev
On 18 Apr 2024, at 12:14, Ruediger Pluem wrote: >> +#define APR_BUFFER_MAX APR_SIZE_MAX/2 > > Why no longer APR_OFF_MAX? As was pointed out, apr_off_t is always 64 bits would still break on Windows. Inside the API, we need a very big, signed, value, and apr_off_t is perfect. Outside the API,

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Yann Ylavic
On Thu, Apr 18, 2024 at 1:16 PM Ruediger Pluem wrote: > > On 4/18/24 12:37 AM, minf...@apache.org wrote: > > Author: minfrin > > Date: Wed Apr 17 22:37:07 2024 > > New Revision: 1917082 > > > > URL: http://svn.apache.org/viewvc?rev=1917082=rev > > Log: > > apr_buffer: Add explicit casts on all

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Ruediger Pluem
On 4/18/24 12:37 AM, minf...@apache.org wrote: > Author: minfrin > Date: Wed Apr 17 22:37:07 2024 > New Revision: 1917082 > > URL: http://svn.apache.org/viewvc?rev=1917082=rev > Log: > apr_buffer: Add explicit casts on all potentially narrowing conversions > to apr_size_t. Define the maximum