bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Bruno Haible <bruno@clisp.org>, bug-gnulib@gnu.org
Subject: Re: Using C2x attributes more effectively in Gnulib
Date: Mon, 9 Aug 2021 03:08:50 -0700	[thread overview]
Message-ID: <997c192f-7736-e0a3-0c04-7596d7bf6f5b@cs.ucla.edu> (raw)
In-Reply-To: <37018291.SK6AWJdEcI@omega>

On 8/7/21 6:40 PM, Bruno Haible 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 = 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.

OK, perhaps this would do instead (assuming C2x):

     SE_SELINUX_INLINE int
     fsetfilecon (int /*fd*/, char const * /*context*/)
       { errno = ENOTSUP; return -1; }
> they have designed
> this language feature from the perspective what the compiler needs in
> order to generate machine code

It's more than just machine code. It's telling the reader that the 
arguments are definitely unused. This gives the reader more information 
than [[maybe_unused]] does.

It's a C2x feature I find helpful from a readability point of view, 
since I find the names to be clutter in situations like these. Indeed, 
I'd rather see something like this:

   SE_SELINUX_INLINE fsetfilecon { errno = ENOTSUP; return -1; }

since setfilecon's signature (which I can easily navigate to, or ask 
about) tells me all I need to know about the API that doesn't matter here.

Admittedly readability tastes differ.

> I have personally used mixed-case macro names in GNU clisp, and I can
> assert (in hindsight) that it did *not* contribute to maintainability.

Fair enough; let's stick to uppercase.

> 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).

It's not merely a technicality. I often write code where an argument may 
be unused, in the sense that there's an ifdef where it's used on some 
platforms but not others. MAYBE_UNUSED is helpful in this situations.

> 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

Yes, this sounds like a win. It's a lot simpler than my proposal. 
Although it loses a bit of information when the arg is definitely 
unused, perhaps that's not worth worrying about.

>> * 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.

Sounds good to me too.


  reply	other threads:[~2021-08-09 10:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-31 19:52 Using C2x attributes more effectively in Gnulib Paul Eggert
2021-08-08  1:40 ` Bruno Haible
2021-08-09 10:08   ` Paul Eggert [this message]
2021-08-22 13:33     ` Bruno Haible
2021-08-22 20:05     ` gnulib-common.m4: Use C2x [[maybe_unused]] when possible Bruno Haible
2021-08-23  1:06     ` snippet/unused-parameter: Mark unused module obsolete Bruno Haible

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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=997c192f-7736-e0a3-0c04-7596d7bf6f5b@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.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: link
Be 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).