Eric Blake <[email protected]> writes: > On Mon, Oct 27, 2025 at 02:51:57PM -0700, Collin Funk wrote: > >> >> I'll bring it up on the libc-alpha list later today. Thankfully it was >> >> caught on Rawhide before a new glibc release. >> > >> > https://www.austingroupbugs.net/view.php?id=1953 tracks the request >> > for clarification from the Austin Group (may take several weeks). >> >> Great! I was hoping you would handle that, since I am less familiar with >> the Austin Group bug reporting format. >> >> I'll reference it in my libc-alpha mail in case we want to wait for >> feedback there. > > The Austin Group visited the proposal today, and went with option 1, > adding the following wording to the standard: > > If the return value is -1, the contents of *lineptr are indeterminate. > > which means that glibc's behavior both before the patch (returning -1 > without changing *lineptr when the file is empty) and after the patch > (unconditionally changing *lineptr to the empty string when returning > -1 at EOF, thereby hiding the last line of the file previously read) > would be in compliance with the updated POSIX wording. The > implication is that the behavior I pointed out in nbdkit assuming the > last line would still be in the buffer is non-portable to updated > POSIX wording, regardless of whether glibc keeps the new behavior, > reverts to the old behavior, or versions the getdelim/getline symbols > to preserve back-compat to programs linked against older versions of > glibc. > > glibc is, of course, welcome to decide if it wants to document a > particular behavior as well-defined even where POSIX says a portable > program must assume indeterminate contents. If glibc wants to define > what POSIX left undefined, then gnulib should ensure that extra > guarantee even on platforms that provide a native getdelim with > behavior that differs from glibc.
Great, thank you for all your help with this! I may revert it considering a point that Florian Weimer raised today. EOF might be an error reading, not an actual end of file, and writing to the buffer is probably incorrect in that case [1]. > For what it's worth, I also inspected the BSD source code, which > appears to blindly truncate the buffer when EOF is encountered without > data, which matches glibc's new behavior: > https://github.com/freebsd/freebsd-src/blob/main/lib/libc/stdio/getdelim.c I did some testing on some other systems and sent the results to [email protected], but copied your email from bugzilla and forgot to replace 'dot' with '.', so you likely did not see [2]. Here is some text copied from that email: Here is a list of platforms with the old glibc behavior: 1. Fedora 43 (glibc 2.42) 2. AIX 7.1.1 and AIX 7.3.3 3. Alpine 3.19.8 (musl 1.2.4_git20230717) 4. OpenBSD 7.7 Here is a list of platforms with the new behavior: 1. MacOS 12.6 2. Solaris 11 3. FreeBSD 14.3 So it was certainly worth clarifying the standard. Collin [1] https://inbox.sourceware.org/libc-alpha/[email protected]/ [2] https://inbox.sourceware.org/libc-alpha/[email protected]/
