From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F3786385843F; Tue, 5 Oct 2021 20:58:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F3786385843F From: "gs-sourceware.org at gluelogic dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.35 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gs-sourceware.org at gluelogic dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2021 20:58:39 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28425 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+ y= ears in software ported to multiple platforms, including alternative libc librar= ies. Using __attribute_xxxxx__ in code allows for `#define __attribute_xxxxx__ /*nothing*/` in environments without support for __attribute__ ((__xxxxx__)= ).=20 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 introduce= d. https://sourceware.org/git/gitweb.cgi?p=3Dglibc.git;h=3D0b5ca7c3e551e5502f3= be3b06453324fe8604e82 https://sourceware.org/git/?p=3Dglibc.git;a=3Dblobdiff;f=3Dmisc/sys/cdefs.h= ;h=3D4dac9d264d28d6ddf8d3ccd99a9d91a3ca410338;hp=3De490fc1aebeadc3dc19b83e1= 8d875d0827b9d695;hb=3D0b5ca7c3e551e5502f3be3b06453324fe8604e82;hpb=3Df3e664= 563361dc17530113b3205998d1f19dc4d9 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)) =3D=3D> 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 --=20 You are receiving this mail because: You are on the CC list for the bug.=