qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] build: include sys/sysmacros.h for major() a


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2] build: include sys/sysmacros.h for major() and minor()
Date: Fri, 30 Dec 2016 11:35:11 +0000

On 29 December 2016 at 13:48, Eric Blake <address@hidden> wrote:
> On 12/28/2016 11:07 AM, Peter Maydell wrote:
>> Also this seems straightforwardly like a bug in glibc: it shouldn't
>> be making this kind of breaking change. makedev(3) on my Linux box
>> says nothing about needing sysmacros.h for these.
>
> Here's the bug explaining the rationale behind the change:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=19239
>
> It IS a bug fix, but in the other direction - it is fixing namespace
> pollution that was present in <sys/types.h> and breaking certain
> standard-required idioms.  There HAS been warning, but system man pages
> have not always been updated to track upstream development, and the plan
> was that glibc 2.25 only causes a warning rather than outright failure
> to compile (although with -Werror, you have to adjust right away, rather
> than when the future glibc actually changes <sys/types.h> again to
> completely drop the pollution).
>
> It is CORRECT to fix any software relying on makedev() to use the
> CORRECT headers for that declaration, rather than getting it for free
> from <sys/types.h> pollution - the problem is that makedev() is not
> portable, and therefore the spelling of the correct header is not
> trivial - it requires some configure-time probing.

I checked a FreeBSD manpage and they don't put these macros
in sysmacros.h, they're in sys/types.h. I think the "correct"
header for them is sys/types.h, because that's where they've
always lived and where they've been documented to be. Otherwise
you're breaking API compatibility.

http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/include/sys/types.h
shows that sys/types.h is where these macros have lived
way back to 2.9BSD in 1983.

If POSIX requires sys/types.h not to provide these macros
then I think you could argue that that's a bug in the POSIX spec,
because it wasn't supposed to make major existing
implementations like the BSD family non-compliant.

For glibc to move to putting these macros somewhere weird
and different to everything else that implements them
is just forcing all programs that use them to add extra
configure machinery and ifdefs for no good reason.
QEMU now has to work around this glibc infelicity, of
course, but it would be better if it didn't have to.

Breaking existing code that was following the docs
is a big deal, and glibc should basically never do
it in my view.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]