On 18 Apr 2024, at 13:15, Yann Ylavic <ylavic....@gmail.com> 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 only reason we can see inside apr_buffer_t is because we want to allocate them on the stack, and make arrays of them, so code outside needs to know the size. > 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 ->size for string vs plain > buffer, and then getting rid of off_t/ssize_t plus all the fancy > signed arithmetics in the apr_buffer code (we don't care about the > sizeof(off_t) or anything like that anymore).. I looked at it, and it was more confusing. Right now, positive is a memory buffer, negative is a string. I don't know why we would need to make it more complicated than that. > Currently apr_buffer_str_make(mystring, strlen(mystring)) is UB, the > API is just broken IMHO. Can you clarify why? What, specifically, is broken, so I can fix it? Regards, Graham --
