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.
next prev parent 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).