Re: [PATCH] stdio-common: Add the fgetln function

[Florian Weimer <fweimer@redhat.com>]

* Paul Eggert:

> On 6/9/22 00:37, Florian Weimer wrote:
>> * Paul Eggert:
>> 
>>> If the stream is not already oriented, FreeBSD getln sets the stream
>>> to byte-orientation. Should glibc getln do the same?
>> Our getdelim doesn't do that explicitly.
>
> I raised the issue because one motivation for adding fgetln is to be
> compatible with FreeBSD. Although the orientation issue is secondary
> and can be detached from the main issue of adding fgetln, it might be 
> helpful to address it while fgetln is being added (assuming it's
> added) rather than later.
>
> Perhaps we'll decide that neither fgetln nor getdelim should change
> orientation, i.e., we're deliberately incompatible with
> FreeBSD. That's OK too.

I will think about it.

>> I'm not sure if it's more efficient.  The I/O block granularity would
>> change depending on where lines end.
>
> Can't we arrange for I/O blocking to be respected as the buffer grows?
> fgetln shouldn't need to stop reading the instant it sees a newline;
> it can read with the same blocksize it always does.
>
> My sense is that a one-buffer solution is more efficient than two
> buffers, where data are copied from one into the other. Of course I 
> haven't measured this though.

I'm not sure if there is a good allocation scheme for this that is
obviously superior to a separate allocation.  If the end of the line
crosses the buffer boundary for the first time, moving the line to the
start of the buffer does not gives of sufficient room for a full block,
so we have to grow the buffer, by at least the number of bytes in the
line prefix read so far.  Not sure if we need some exponential resizing
policy there.  Assuming that the line is reasonably long, we will then
find a line terminator in the newly read block, and can return a pointer
to the start of the buffer from fgetln.

But we would have to teach the rest of libio to avoid the extra buffer
space at the end during future read operations.  We could avoid these
changes if we resized the buffer to twice the original buffer size.
Then we'd still maintain buffer read alignment, just with a larger
buffer.  But that runs counter to the goal of avoiding extra
allocations.

Thanks,
Florian