On 8/27/21 8:56 AM, Rich Felker wrote: > On Thu, Aug 26, 2021 at 03:56:47PM -0700, enh wrote: >> On Thu, Aug 26, 2021 at 2:34 PM Rob Landley <[email protected]> wrote: > > Rob asked me for some input on this: > >> > In my private emails somebody is trying to make the last aboriginal linux >> > release work and the old busybox isn't building anymore because makedev() >> > used >> > to be in #include <sys/types.h> and now it's moved to <sys/sysmacros.h>. >> > (Why? I >> > dunno. Third base.) > > This was glibc bug #19239, and clearly needed to be fixed. Generic > lowercase macro names like "major" and "minor" are *extreme* namespace > pollution for a standard header to be doing.
I stared at that a bit before figuring out you were objecting because they're MACROS. (Generic words being FUNCTION names from headers is common: stdio.h defines remove(), rename(), rewind()... stdlib.h has random(), free(), abort(), exit()...) > sys/sysmacros.h was > always the correct way to get these macros on glibc, but for whatever > reason (compatibility with some ancient historic unices?) glibc was > making sys/types.h include sys/sysmacros.h implicitly, at least under > some profiles. The problem is the man page said to #include <sys/types.h> to get it, so that's what people did. And even today the man page doesn't particularly call them out as macros, it gives them function prototypes and even calls them functions: The major() and minor() functions perform the converse task: given a device ID, they return, respectively, the major and minor components. I thought it was like getc() being officially undecided about whether or not it's a macro. (Could be either way.) > What made this even worse was that, under BSD or GNU profile > (including by default), glibc's stdlib.h included sys/types.h. This > meant anything using stdlib.h got the namespace breakage. Is it "breakage" if it's the standard for Linux and has been for years? I had a function called throw() in a turbo C++ program I wrote for DOS back in college and a compiler upgrade turned that into a keyword and broke my stuff because they'd decided to gratuitously add stuff to the language AFTER I wrote my code. If it had been "compiling it on Linux behaves differently" I wouldn't have minded so much, it was a version upgrade of the same THING breaking stuff that bothered me. > In commit f552c792c7ce5a560f214e1104d93ee5b0833967 (2011) musl > emulated this glibc behavior in _GNU_SOURCE profile, but commit > a31a30a0076c284133c0f4dfa32b8b37883ac930 (2019) removed it since glibc > had already fixed the problem and pushed applications still depending > on the wrong behavior to fix their stuff. So sys/types.h couldn't have prototyped the functions (inside #ifndef if necessary) and sys/macros.h couldn't have defined faster macro vesions then, and you get whichever one you #include first? Eh, water over the bridge. Glibc decided to break userspace and musl fell in line a few years later. I'm just not convinced glibc made a good call. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
