> On 22 Jan 2020, at 01:41, David Fetter <david@fetter.org> wrote:
>
> On Tue, Jan 21, 2020 at 07:05:47PM +0100, David Fetter wrote:
>> On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote:
>>> On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote:
>>>> On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote:
>>>>> I think we should be using a macro to define the maximum length, rather
>>>>> than have 100 used in various places.
>>>>
>>>> It's not just 100 in some places. It's different in different places,
>>>> which goes to your point.
>>>>
>>>> How about using a system that doesn't meaningfully impose a maximum
>>>> length? The shell variable is a const char *, so why not just
>>>> re(p)alloc as needed?
>>>
>>> Uh, how do you know how big to make the buffer that receives the read?
>>
>> You can start at any size, possibly even 100, and then increase the
>> size in a loop along the lines of (untested)
It doesn't seem like a terribly safe pattern to have the client decide the read
buffer without disclosing the size, and have the server resize the input buffer
to an arbitrary size as input comes in.
> my_size *= 2;
> buf = (char *) realloc(buf, my_size);
I know it's just example code, but using buf as the input to realloc like this
risks a memleak when realloc fails as the original buf pointer is overwritten.
Using a temporary pointer for ther returnvalue avoids that, which is how
pg_repalloc and repalloc does it.
cheers ./daniel