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

On 18 Apr 2024, at 13:15, Yann Ylavic <[email protected]> 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
--