[Toybox] [PATCH] include sys/sysmacros.h

[enh]

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 <dalias at libc.org> 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
> Toybox at lists.landley.net
> 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.

 1456804329.0