This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] Deprecate inclusion of sys/sysmacros.h by sys/types.h.
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 25 Apr 2016 09:50:45 -0400
- Subject: Re: [PATCH 2/2] Deprecate inclusion of sys/sysmacros.h by sys/types.h.
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1461444595 dot git dot zackw at panix dot com> <361004a869a7731e6f8161be9fe5da9c5446dc99 dot 1461444595 dot git dot zackw at panix dot com> <571DC63C dot 7080708 at redhat dot com>
On Mon, Apr 25, 2016 at 3:24 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 11/19/2015 05:11 AM, Zack Weinberg wrote:
>
>> * misc/Versions [GLIBC_2.24]: Add gnu_dev_major, gnu_dev_minor,
>> and gnu_dev_makedev.
>
> Why do we need these new functions? Recent GCC has support for emitting
> warnings from macros, if that's what you need.
I should maybe split the patch again to make clearer what is going on.
These functions exist already for Linux-based configurations; I promoted
them to generic so that the new bits/sysmacros.h could contain only the
minimum amount of system-specific logic.
The functions are *needed* because the Linux kernel encoding of dev_t
values is complicated. Pure macro implementations of major, minor,
makedev could only avoid evaluating their arguments multiple times by
resorting to the ({ ... }) extension, which is no good for a header
that has to work with any compiler. Instead, the original author of
sysdeps/.../linux/sys/sysmacros.h went for inline functions, with
out-of-line fallbacks in case inlining is suppressed or unavailable.
I imagine we wouldn't name those functions gnu_dev_(major|minor|makedev)
nowadays, but they're in the ABI already.
I shall look into the warnings-from-macros feature; maybe it will get
me out of having to use __REDIRECT.
>> * misc/sys/cdefs.h: Add __attribute_deprecated_msg__, wrapping
>> GCC >=4.5's ability to specify a detailed deprecation message.
>
> That should probably go into a separate patch.
Do you think it can be lumped with the addition of __clang_has_extension,
or should each of those be separate patches?
zw