[PATCH] libio: Add terminating NUL when the first character is EOF in getdelim [BZ #28038]

[Adhemerval Zanella Netto]

On 28/10/25 23:24, Collin Funk wrote:
> Hi Florian,
> 
> Florian Weimer <fweimer@redhat.com> said:
> 
>> * Collin Funk:
>>
>>> POSIX requires that the buffer used by getdelim/getline add a
>>> terminating NUL whenever an EOF is read.
>>>
>>> * libio/iogetdelim.c (__getdelim): Add a NUL byte when the first
>>> __underflow is called.
>>> * libio/tst-getdelim.c (do_test): Add a test case for the bug.
>>>
>>> -- 8< --
>>>
>>> If this patch is okay for glibc, then I will push it to Gnulib as well
>>> since the function is mostly copied over there.
>>>
>>> ---
>>>  libio/iogetdelim.c   |  1 +
>>>  libio/tst-getdelim.c | 17 +++++++++++++++++
>>>  2 files changed, 18 insertions(+)
>>>
>>> diff --git a/libio/iogetdelim.c b/libio/iogetdelim.c
>>> index 0bfaef227a..1d89757352 100644
>>> --- a/libio/iogetdelim.c
>>> +++ b/libio/iogetdelim.c
>>> @@ -77,6 +77,7 @@ __getdelim (char **lineptr, size_t *n, int delimiter, FILE *fp)
>>>        if (__underflow (fp) == EOF)
>>>  	{
>>>  	  result = -1;
>>> +	  (*lineptr)[0] = '\0';
>>>  	  goto unlock_return;
>>>  	}
>>>        len = fp->_IO_read_end - fp->_IO_read_ptr;
>>
>> Looks okay.  The buffer is already allocated at this point.  I don't
>> think there is backwards compatibility impact.
> 
> I had thought this was harmless as well, but now am considering
> reverting it or introducing a compat symbol.
> 
> There is more discussion in the bug report and on bug-gnulib [1][2]. The
> shortened story is that nbdkit used a loop like the following to get the
> last line of 'du -cs':
> 
>     while (getline (&line, &len, fp) != -1)
>       ;
>     /* Process last line stored in LINE.  */
> 
> This code was buggy before my patch in the rare case that 'du' produced
> no output. But they noticed it upon testing on Rawhide because after a
> normal invocation line[0] == '\0' instead of having the last line.
> 
> Since the original standardization of getline/getdelim was based on the
> existing glibc functions, Eric Blake opened a bug report with the Austin
> Group to request clarification on this [3].
> 
> I'm a bit torn on which behavior is better, so others thoughts would be
> appreciated.
> 

This change did raise a potential latent issue with ndbkit, although
we potentially break it when running old version on newer glibc. 
Do you know the behavior of other libcs?

I think the change does close a potential UB in this interface, but
this kind of break signal that we should keep old behavior as compat
symbol. 

I think we might wait Austin clarification until the release to check 
if move old semantic to a compat symbol or if we revert this patch.
  
In any case, I think we should do it before the next release.

> Collin
> 
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28038
> [2] https://lists.gnu.org/archive/html/bug-gnulib/2025-10/msg00096.html
> [3] https://www.austingroupbugs.net/view.php?id=1953