From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DA1331F8C6 for ; Sun, 8 Aug 2021 01:41:17 +0000 (UTC) Received: from localhost ([::1]:37650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mCXoS-0001vL-Mm for normalperson@yhbt.net; Sat, 07 Aug 2021 21:41:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32778) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCXoO-0001v9-P6 for bug-gnulib@gnu.org; Sat, 07 Aug 2021 21:41:12 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.22]:36732) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCXoM-00062t-LG for bug-gnulib@gnu.org; Sat, 07 Aug 2021 21:41:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1628386858; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=FGCuiLes31QV5FVPf//qz/i24BA1fW64j/JpgS4J7to=; b=a+rR7r97zfFZE4Mqbf2RTS1wD9GITr9QkpHybpEb7uiME8w5TcvZJ8xJX5lI0d7KKA r+7qrHj3lbM2yuZdHjafJ8JoIF2lTiyIVPI+3CGswwfDmwtWr2uVP5550e3HMtbNCewS Ihw2h1yqcFoclv7i2m38Ci1/OSFKUV/cT09wvotUaSUn5JBa/ZENdFtrRnnF7hm4xsBb yPVjnt0MQ8MWLvwnKyfrEXMfpY5YfkwSucJ2ceKvoPr6J6hxnfcyyNuLd8GH2XTAKJBw +sHc8dqiknrltEu3+Jxs7nsgAYHxQ2xvxdFeZRru4lZwgbicF/02bF+nwqP1elub0Akf zVRg== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH/DXj0JGsbh0vbrMZq" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.31.0 DYNA|AUTH) with ESMTPSA id I0a189x781ewGIN (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Sun, 8 Aug 2021 03:40:58 +0200 (CEST) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: Using C2x attributes more effectively in Gnulib Date: Sun, 08 Aug 2021 03:40:57 +0200 Message-ID: <37018291.SK6AWJdEcI@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <0ed0a5a4-ed41-7d40-1c31-f422b55e7ab3@cs.ucla.edu> References: <0ed0a5a4-ed41-7d40-1c31-f422b55e7ab3@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.22; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paul Eggert Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Paul, > Because draft C2x requires using [[maybe_unused]] before a parameter > instead of after, the recent C2x-related changes to Gnulib caused me to > move all uses of _GL_UNUSED_PARAMETER Agreed. We should follow standards. The new standard picked a different position for the marker than what we used to have. > _GL_ATTRIBUTE_MAYBE_UNUSED is too long, so I propose we rename > it to something shorter. In implementation code, it is more convenient to include "attribute.h" and then use MAYBE_UNUSED. The names with _GL_ prefix are, IMO, only for places where including "attribute.h" is not desired, namely in public header files. And in public header files we don't have many function definitions that ignore some arguments. It's basically only lib/se-context.in.h lib/se-label.in.h lib/se-selinux.in.h IMO that's not enough justification for introducing a new name for _GL_ATTRIBUTE_MAYBE_UNUSED. > Also, draft C2x lets one write the above function without naming the > parameters, as follows: > > SE_SELINUX_INLINE int > fsetfilecon (int, char const *) > { errno = ENOTSUP; return -1; } > > This is nicer than [[maybe_unused]], because it says the arguments are > *definitely* unused instead of merely *maybe* unused, and that allows a > bit more checking of the code. I disagree on this one. For a human reader who wants to understand the code, the parameter name is more important than its type. Therefore, for maintainability your example should better read SE_SELINUX_INLINE int fsetfilecon (fd, context) { errno = ENOTSUP; return -1; } In other words, it is a misfeature in the standard. They have designed this language feature from the perspective what the compiler needs in order to generate machine code, not from the perspective of the programmer and maintainability. So, we should better not use this misfeature. > So, how about the following ideas: > > * Rename _GL_ATTRIBUTE_MAYBE_UNUSED to _GL_maybe_unused. Similarly for > _GL_deprecated, _GL_fallthrough, and _GL_nodiscard. Ohhhhhh. This breaks a decades-long convention. We have the convention in GNU that macro names are upper case, to distinguish them from function and variable names. This is good convention. I have personally used mixed-case macro names in GNU clisp, and I can assert (in hindsight) that it did *not* contribute to maintainability. > As C2x becomes more > popular, it'll be easy to read _GL_deprecated as shorthand for > "[[deprecated]] if supported, empty otherwise". Whether the expansion is mainly lowercase or not, is irrelevant. Breaking said convention is not good. > * Remove all uses of _GL_UNUSED after arguments in Gnulib, replacing > them with _GL_maybe_unused before arguments. This will support non-GCC > C2x compilers better. Deprecate _GL_UNUSED. Hmm. This _GL_UNUSED macro is used a lot in .c code, simply because it it short (and the "maybe" in _GL_ATTRIBUTE_MAYBE_UNUSED is more of a compiler technicality). I'm OK with moving all _GL_UNUSED from after the parameter declaration to before the parameter declaration. Then we can continue to have #define _GL_UNUSED _GL_ATTRIBUTE_MAYBE_UNUSED > * Define a macro _GL_UNUSED_ARG(TYPE, NAME) that expands to 'TYPE' in > draft C2x, and to '_GL_maybe_unused TYPE NAME' otherwise. That way, one > can write: > > SE_SELINUX_INLINE int > fsetfilecon (_GL_UNUSED_ARG (int, fd), > _GL_UNUSED_ARG (char const *, con)) > { errno = ENOTSUP; return -1; } Such macros with type parameters have two problems: * Maintainability problem: The reader needs to understand the macro first, before they can understand the declaration. Whereas when the declaration reads SE_SELINUX_INLINE int fsetfilecon (_GL_UNUSED int fd, _GL_UNUSED char const *con) the reader understands 70% of the syntax and can treat _GL_UNUSED as "some token I don't need to know about". * It doesn't apply to function types that are not typedefs. How would you write int foo (_GL_UNUSED int (*p) (const void *) ) ? > * Define a macro _GL_UNUSED_ARGNAME(NAME) that expands to NAME if not > draft C2x, empty otherwise. Programs can use this macro for complicated > argument types where _GL_UNUSED_ARG does not suffice, e.g., > '_GL_maybe_unused int (*_GL_UNUSED_ARGNAME (p)) (int)'. I object for two reasons: - it's a macro with type parameter (see above), - its purpose is just to make use of a misfeature in the language (see above as well). > * Remove the snippet/unused-parameter module as it's not used now. Indeed, this module is unused in gnulib. It may be used in packages that use gnulib; therefore I vote for marking it 'obsolete' and remove it only in a year or two. Bruno