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, 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 CCD7A1F8C6 for ; Sun, 22 Aug 2021 13:34:56 +0000 (UTC) Received: from localhost ([::1]:43662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mHncl-0003y1-8l for normalperson@yhbt.net; Sun, 22 Aug 2021 09:34:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41658) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mHnbr-0001nk-Gm for bug-gnulib@gnu.org; Sun, 22 Aug 2021 09:34:00 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.21]:31214) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mHnbn-00046g-SD for bug-gnulib@gnu.org; Sun, 22 Aug 2021 09:33:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1629639232; 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=U5moXJ/UUAS3HN0dC+EOR8LjCa/u2aqe1oBWkkRv3TQ=; b=VWRurnODkWmhCQ4N6l7DmUA+VTarn6hvyGSGDkTgII578eMg+MeJ1dXN4TElZa2ZQK O92NutR8ILW7Vn27XuNY++fBb2BMqBrKZoaO2SlnOxNjTKJ7pX+n7Z0EqVfZMD1ObHBz MS2J73r8GBhhPzHQ4ELhSg845AHCrl7YwLfLDyM0DSTUHioZ7ZHJUPDaODqBzgIInCNq k7Nhx/5pZ3oFlpqHlnXwUgnvtSm8P1J5P02f4wyS201yqhzepoE5y0C7nrF4kGZrGCsz 37moAFvRhGrSyu15rR7h1+wAi23Ud+ZliSMuYQxFsDoSbZr1bEDfYxPpDv+V1V4vsgQP c8tg== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94z26ll5ip69ukEWxMMoz6TatjeiwMVn8eJlEag==" X-RZG-CLASS-ID: mo00 Received: from omega.localnet by smtp.strato.de (RZmta 47.31.0 AUTH) with ESMTPSA id I0a189x7MDXpa8S (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 22 Aug 2021 15:33:51 +0200 (CEST) From: Bruno Haible To: Paul Eggert Subject: Re: Using C2x attributes more effectively in Gnulib Date: Sun, 22 Aug 2021 15:33:51 +0200 Message-ID: <3459081.jE0xQCEvom@omega> In-Reply-To: <997c192f-7736-e0a3-0c04-7596d7bf6f5b@cs.ucla.edu> References: <0ed0a5a4-ed41-7d40-1c31-f422b55e7ab3@cs.ucla.edu> <37018291.SK6AWJdEcI@omega> <997c192f-7736-e0a3-0c04-7596d7bf6f5b@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Received-SPF: none client-ip=85.215.255.21; 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, 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: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Paul Eggert wrote: > >> Also, draft C2x lets one write the above function without naming the > >> parameters, as follows: > >> > >> SE_SELINUX_INLINE int > >> fsetfilecon (int, char const *) > >> { errno =3D 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. > >=20 > > I disagree on this one. For a human reader who wants to understand the = code, > > the parameter name is more important than its type. >=20 > OK, perhaps this would do instead (assuming C2x): >=20 > SE_SELINUX_INLINE int > fsetfilecon (int /*fd*/, char const * /*context*/) > { errno =3D ENOTSUP; return -1; } Yes, this style is fine with me. The human reader understands what each argument designates. > > they have designed > > this language feature from the perspective what the compiler needs in > > order to generate machine code >=20 > It's more than just machine code. It's telling the reader that the=20 > arguments are definitely unused. This gives the reader more information=20 > than [[maybe_unused]] does. True. But I dislike that there is no [[unused]] / [[definitely_unused]] mar= ker; they have picked a completely different syntax for the unused parameter than for [[maybe_unused]]. Also, I think/hope that [[maybe_unused]] will not be used in .h files, only in .c files. Then, in .c files we can #include "attributes.h". > It's a C2x feature I find helpful from a readability point of view,=20 > since I find the names to be clutter in situations like these. Indeed,=20 > I'd rather see something like this: >=20 > SE_SELINUX_INLINE fsetfilecon { errno =3D ENOTSUP; return -1; } >=20 > since setfilecon's signature (which I can easily navigate to, or ask=20 > about) tells me all I need to know about the API that doesn't matter here. This syntax =E2=80=94 defining a function without specifying its prototype = =E2=80=94 looks quite odd in C. By the way, the "which I can easily navigate to" idea is fallacious: It lea= ds to programming languages that _depend_ on a development environment. Yes, in a development environment you can easily navigate between declaration and definition. However, it is frequent to consider patch files sent by mail, to do temporary edits on remote machines where no development environment is installed, or [not in GNU, but elsewhere] to perform code reviews through a web-based interface. In these cases the user doesn't have a development environment. > > I have personally used mixed-case macro names in GNU clisp, and I can > > assert (in hindsight) that it did *not* contribute to maintainability. >=20 > Fair enough; let's stick to uppercase. Thanks. > > 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 >=20 > Yes, this sounds like a win. It's a lot simpler than my proposal.=20 > Although it loses a bit of information when the arg is definitely=20 > unused, perhaps that's not worth worrying about. OK, I'll do that. > >> * Remove the snippet/unused-parameter module as it's not used now. > >=20 > > 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 on= ly > > in a year or two. >=20 > Sounds good to me too. I'll do that too. Bruno