public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "gs-sourceware.org at gluelogic dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/28425] New: new __attribute_nonnull__(params) conflicts with third-party Date: Tue, 05 Oct 2021 20:58:38 +0000 [thread overview] Message-ID: <bug-28425-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=28425 Bug ID: 28425 Summary: new __attribute_nonnull__(params) conflicts with third-party Product: glibc Version: 2.35 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libc Assignee: unassigned at sourceware dot org Reporter: gs-sourceware.org at gluelogic dot com CC: drepper.fsp at gmail dot com Target Milestone: --- new __attribute_nonnull__(params) conflicts with third-party (Staring with a summary, then following with details.) I am fully aware that leading _ and leading __ and any __ are reserved in C indentifiers. This bug report suggests a patch to hopefully reduce breakage caused by the introduction of __attribute_nonnull__. ``` diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h index 4dac9d264d..70d6ef37f4 100644 --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -329,7 +329,7 @@ # endif #endif #ifndef __nonnull -# define __nonnull(params) __attribute_nonnull__ (params) +# define __nonnull(params) __attribute__ ((__nonnull__ params)) #endif /* The returns_nonnull function attribute marks the return type of the function ``` Details __attribute_xxxxx__ is a useful idiom that I and others have used for 20+ years in software ported to multiple platforms, including alternative libc libraries. Using __attribute_xxxxx__ in code allows for `#define __attribute_xxxxx__ /*nothing*/` in environments without support for __attribute__ ((__xxxxx__)). For example: https://github.com/gstrauss/plasma/blob/master/plasma_attr.h#L213 ``` #ifndef __attribute_nonnull__ #if __has_attribute(nonnull) \ || __GNUC_PREREQ(3,3) #define __attribute_nonnull__ __attribute__((__nonnull__)) #else #define __attribute_nonnull__ #endif #endif ``` I have used the above for some 20+ years with compilers including gcc, clang, Sun Studio cc, IBM xlc, HP acc on Linux, *BSD, Solaris, AIX, HPUX Code can be annotated with __attribute_nonull__ and the attribute is defined for compilers which support it, and defined to a no-op for those which do not. I have the same code in the lighttpd web server https://github.com/lighttpd/lighttpd1.4/blob/master/src/first.h#L246 Unfortunately, there is a limitation in C in how macros are handled with and without arguments. In glibc 2.35 development, __attribute_nonnull__(params) has been introduced. https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0b5ca7c3e551e5502f3be3b06453324fe8604e82 https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=misc/sys/cdefs.h;h=4dac9d264d28d6ddf8d3ccd99a9d91a3ca410338;hp=e490fc1aebeadc3dc19b83e18d875d0827b9d695;hb=0b5ca7c3e551e5502f3be3b06453324fe8604e82;hpb=f3e664563361dc17530113b3205998d1f19dc4d9 This breaks pre-existing usage of the idiom __attribute_nonnull__ if used *without params* Some gcc attributes take an *optional* argument, e.g. __nonnull__, __deprecated__, __sentinel__ In https://github.com/gstrauss/plasma, I differentiated with macros __attribute_nonnull__ and __attribute_nonnull_x__(params) I am not saying this is the only solution, but it does differentiate. Unfortunately, the new macro in glibc for __attribute_nonnull__(params) breaks historical usage of __attribute_nonnull__ without params. As I mentioned above, I recognize that leading __ names are reserved for the system libraries, and it is glibc's prerogative to define the macro for __attribute_nonnull__ however glibc developers please. There is already macro __nonnull(params) in gcc and clang #define __nonnull(params) __attribute__ ((__nonnull__ params)) ==> For greatest compatibility, I kindly request that glibc 2.35 *not define* __attribute_nonull__ at all and instead continue to use __nonnull(params) If not, then please consider the patch at the top of this post which continues to define __nonnull(params) directly to #define __nonnull(params) __attribute__ ((__nonnull__ params)) so that others who may have used the __attribute_nonnull__ idiom do not have to track down weird compiler errors from system headers using __nonnull(params) in addition to the application code which uses __attribute_nonnull__ without params. The impetus for this bug report is that lighttpd 1.4.60 release breaks in Fedora Rawhide (which is using glibc 2.34.9000), due to both lighttpd and glibc 2.34.9000 having different definitions for __attribute_nonnull__. lighttpd usage of __attribute_nonull__ does not expect __attribute_nonnull__(params) to require parameters, leading to compiler errors where lighttpd headers uses __attribute_nonnull__ without params. Thank you. Glenn -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2021-10-05 20:58 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-05 20:58 gs-sourceware.org at gluelogic dot com [this message] 2021-10-05 20:58 ` [Bug libc/28425] " gs-sourceware.org at gluelogic dot com 2021-10-05 23:26 ` gs-sourceware.org at gluelogic dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-28425-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).