LWN: Comments on "GNU C Library 2.28 released"

GNU C Library 2.28 released

zwol — Mon, 06 Aug 2018 14:54:15 +0000

I haven't thought that possibility through in detail, but I believe it would just change the set of programs that break, and in some ways it would be worse, because macros can be #undef-ed, but file-scope symbols can't.

GNU C Library 2.28 released

dezgeg — Sat, 04 Aug 2018 00:35:45 +0000

Couldn't those symbols be changed from macros to inline functions instead?

GNU C Library 2.28 released

zwol — Fri, 03 Aug 2018 14:20:02 +0000

All of the stdio.h input functions besides fgetc are required to behave as-if they internally make a series of calls to fgetc (7.21.3p11), so a sticky-EOF requirement for fgetc inherits to all of the other functions.

The wording for fgetc _was_ ambiguous in C89, but it was changed in C99, and if you dig up the defect report (I don't remember the number off the top of my head) it's very clear that the committee meant to make EOF a sticky condition. It has always been sticky in the BSD lineage; glibc actually had a note in the code saying "we deviate from the standard for SysV compatibility" but nowadays we think BSD compatibility is more important.

GNU C Library 2.28 released

zwol — Fri, 03 Aug 2018 14:11:45 +0000

Yeah, nobody was super happy about breaking compatibility with *BSD in this way, but it wasn't simply a 'theoretical namespace purity' problem. Perfectly ordinary-looking C++ programs like this

#include <iostream>
class Foo {
int major;
public:
Foo(int maj) : major(maj) {}
// ...
};

would fail to compile on (GNU/)Linux with apparently nonsensical error messages:

test.cc: In constructor ‘Foo::Foo(int)’:
test.cc:6:18: error: class ‘Foo’ does not have any field named ‘gnu_dev_major’

because, you see, libstdc++'s headers define _GNU_SOURCE for you, and many of them also include <stdlib.h>, and when _GNU_SOURCE is on, glibc's <stdlib.h> includes <sys/types.h>.

There isn't any particularly good reason for <stdlib.h> to include <sys/types.h> under _GNU_SOURCE, but taking it out broke hundreds of programs in test rebuilds of Debian and Fedora. libstdc++ defining _GNU_SOURCE is agreed to be a bug, but fixing it is really hard, due to the sheer variety of things the C++ library is required to do from inline code in its headers, some of which can't be accomplished using only the facilities of ISO C, or even ISO C + POSIX.1-2008.

So we decided that breaking the smaller number of programs that actually _need_ the major/minor/mkdev macros was the least bad option.

GNU C Library 2.28 released

pm215 — Fri, 03 Aug 2018 09:33:57 +0000

On the other hand, these macros have lived in sys/types.h forever right back to 2.9BSD. I think it's a mistake that glibc has broken source compatibility and forced everybody else to gratuitously update their code (which was following the documentation for which header to use for them), including possibly now having to have configure machinery for checking "are we running with a glibc that's done something incompatible with the rest of the world", purely to fix a theoretical namespace purity issue.

GNU C Library 2.28 released

dirtyepic — Fri, 03 Aug 2018 05:12:01 +0000

To be fair though, if I were an upstream and my package worked fine everywhere except on Gentoo's "non-standard" glibc, I might also be a bit skeptical, or at the very least it would be pretty low on my list of priorities until it actually became a problem.

IIRC the reason for backporting the types.h change was to provide glibc upstream with some data on how much real world code would break. In that it succeeded. What I find disappointing is the duplication of effort as every distro pulls in the new version and starts the tedious process of rebuilding their repos and patching failing packages. All that work has already been done and has been for a while. It would have been nice to have had it all fixed upstream and save everyone some time.

GNU C Library 2.28 released

flussence — Thu, 02 Aug 2018 23:02:01 +0000

That's exactly what prompted my comment. I was trying to write an ebuild for some random github project that insisted on using a customised/bundled copy of Python 2, and couldn't convince them that all those things are bad ideas in isolation, let alone together as they were.

They've had half a year and done nothing about it, the technical debt collector is about to come knocking.

GNU C Library 2.28 released

eru — Thu, 02 Aug 2018 20:31:33 +0000

fgets() is one of the interfaces that should not be there. It looks simple enough (therefore beginners often write line by line readers with it), but using it in a truly robust way is tricky.

GNU C Library 2.28 released

Lekensteyn — Thu, 02 Aug 2018 10:39:28 +0000

* All stdio functions now treat end-of-file as a sticky condition. If you read from a file until EOF, and then the file is enlarged by another process, you must call clearerr or another function with the same effect (e.g. fseek, rewind) before you can read the additional data. This corrects a longstanding C99 conformance bug. It is most likely to affect programs that use stdio to read interactive input from a terminal. (Bug #1190.)

Sigh, I know of at least one application that will break, it assumed that reading after EOF is possible if new data was appended later on. C99 about fgetc:

If the end-of-file indicator for the stream is set, or if the stream is at end-of-file, the end-of-file indicator for the stream is set and the fgetc function returns EOF.

C99 about fgets:

No additional characters are read after a new-line character (which is retained) or after end-of-file.

This is a bit ambiguous, possible interpretations for when to stop reading (assuming no new-line characters):

if the stream is at the end-of-file (previous behavior, reasonable).
if the end-of-file indicator for the stream is set (new behavior).

POSIX fgets says:

Upon successful completion, fgets() shall return s. If the stream is at end-of-file, the end-of-file indicator for the stream shall be set and fgets() shall return a null pointer.

Arguably the new glibc behavior is also non-compliant. "Upon successful completion" does not suggest that previous error conditions should be sticky.

GNU C Library 2.28 released

dirtyepic — Thu, 02 Aug 2018 02:39:07 +0000

It's unfortunate that many of those patches were ignored or rejected by projects when they tried to upstream them. Maybe next time.

GNU C Library 2.28 released

flussence — Thu, 02 Aug 2018 00:30:27 +0000

The sysmacros.h change is going to bite quite a few people; Gentoo has been shipping it with that patch for a year or two and a lot of downstream code also needed patching, one of the notable ones being Python 2.

GNU C Library 2.28 released

welinder — Wed, 01 Aug 2018 15:54:03 +0000

Note #22644 which is really understated. A somewhat more blunt description would be

"Running 32-bit x86 code with pre-2.28 libc will suffer from seemingly random memory
corruption."

It's particularly easily to hit with std::vector.