seems like that glibc thread ground to a halt? did anyone actually rebuild debian with such a change? did glibc make this change? has it shipped yet?
we had the same major/minor pollution bug reported against bionic but closed it as WAI saying that that's what glibc does. but if glibc removes the transitive #include, i'd love to. On Mon, Feb 29, 2016 at 7:36 PM, Rich Felker <[email protected]> wrote: > On Mon, Feb 29, 2016 at 05:53:02PM -0500, Mike Frysinger wrote: >> On 29 Feb 2016 16:24, Rob Landley wrote: >> > On 02/29/2016 12:36 PM, Mike Frysinger wrote: >> > > The major/minor macros are defined in sys/sysmacros.h. This has >> > > historically been pulled in implicitly by sys/types.h, >> > >> > http://man7.org/linux/man-pages/man3/major.3.html says sys/types.h, yes. >> >> this is merely documenting what glibc has historically done, and glibc >> has historically tried to copy BSD in this area. even then, the manpage >> probably should be adjusted to document sysmacros.h directly since that >> is where glibc has always placed things. > > Defining macros named "major" and "minor" from a standard header is > serious namespace pollution. > > Since sys/types.h is a rather quirky historical header that nobody > needs to include anyway, it's not such a horrible thing that glibc's > sys/types.h exposes sys/sysmacros.h However, also for historical > reasons, glibc's stdlib.h includes sys/types.h. This means that every > source file which includes stdlib.h gets the namespace pollution, and > that's really bad. That's why they're trying to fix it. > >> > > but C libs >> > > are moving away from that as they aren't in POSIX. Use the header >> > > directly as defined by BSD systems. >> > >> > This adds a non-posix header to the posix header section of toys.h, >> >> i really have no idea how toybox code is structured. feel free to add >> the include to wherever you feel is appropriate. >> >> > based on the premise that unspecified C libraries plan to break existing >> > programs at some unknown point in the future, for no obvious reason. >> >> feel free to read the thread: >> https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html >> >> glibc is the process of deprecating, and musl/uClibc would follow suit, >> if not just drop the include altogether. > > musl has never had the issue. :-) because we don't implicitly include > sys/sysmacros.h at all. The set of programs that have any use for > these macros is basically ls, mknod, and archivers (tar, cpio, etc.) > that support archiving device nodes, and these programs can just > include the appropriate header to get them. > > Rich > _______________________________________________ > Toybox mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
