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

[Collin Funk]

Eric Blake <eblake@redhat.com> writes:

> 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.

Thanks! I'll work on a patch that reverts the previous change and
documents the behavior. The subsequent Gnulib patch should be simple as
well. It is just adjusting the tests that I added for this to expect the
opposite.

>> >   
>> > 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).

I'm going to file an Austin Group issue soon, maybe that one will be
quick as well.

My head hurt trying to think about how 'dd conv=lcase' would handle
multibyte characters. But it seems that there was agreement in 2011
that 'dd' should only handle unibyte character sets [1]. However, it
seems no one opened a bug report as the meeting notes mentioned, so the
standard never got updated. :(

Collin

[1] https://www.opengroup.org/austin/docs/austin_539.txt