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

[Eric Blake]

On Sun, Nov 02, 2025 at 12:08:44PM -0800, Collin Funk wrote:
> Hi Adhemerval,
> 
> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
> 
> > This change did raise a potential latent issue with ndbkit, although
> > we potentially break it when running old version on newer glibc.
...
> 
> > 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.

The Austin Group made their decision today:

https://www.austingroupbugs.net/bug_view_page.php?bug_id=1953

in short, starting a 30-day interpretation request to clarify the
standard by option 1 on that page.  Most relevant would be the
addition to the future standard the line:

    If the return value is -1, the contents of *lineptr are indeterminate.

which specifically permits both the old glibc behavior and the patched
behavior as compliant implementations, and renders the nbdkit reliance
on being able to access the last line of a non-seekable pipeline in
the buffer once getline() returns -1 as non-portable at least in terms
of POSIX.

Since the glibc patch was originally applied to try to comply with a
specific reading of POSIX, but POSIX would no longer mandate that
particular interpretation, we could revert the patch entirely.

Or, if we think the UB avoidance behavior of never letting the buffer
lack a NUL terminator even when the function returns -1 is worth the
benefit for programmers (and for symmetry with other platforms that
have that behavior), then we can keep the patch, but I would recommend
versioning the symbol to avoid breaking older clients that expected
the older behavior of the buffer remaining untouched.

Either way, I would recommend that glibc consider documenting its
behavior going forward (POSIX may state things are indeterminate, but
we are always free to extend POSIX with our own guarantees in those
situations).

I don't have any strong opinions as to which course glibc should take;
but I do think that gnulib should match whatever behavior glibc
decides on, since we have now got a good list of multiple other libcs
that are split on which behavior makes more sense.

> >   
> > In any case, I think we should do it before the next release.
> 
> Agreed, certainly before the next release.

I'm actually quite pleased that the Austin Group managed to visit an
issue in less than a month from when it was first filed!  There is
still a 30-day window before today's Austin Group decision becomes
formal, in case someone wants to point out a reason why the decision
might need to be revised, but usually the 30-day notice is not
challenged.  I don't know the timeline for when glibc has to lock in
its decision on how the next release will behave.  If the next glibc
release needs to happen before the POSIX 30-day timer makes the
direction forward more stable, I would recommend reverting now and
revisiting for a later glibc release (if the 30-day review gives
reason for the Austin Group to revise its decision, it's better to
change glibc behavior only once to the finalized wording, rather than
have two releases in a row with two different behaviors).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org