Re: Using C2x attributes more effectively in Gnulib

[Bruno Haible]

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 = 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; }

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

True. But I dislike that there is no [[unused]] / [[definitely_unused]] marker;
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, 
> 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.

This syntax — defining a function without specifying its prototype — looks
quite odd in C.

By the way, the "which I can easily navigate to" idea is fallacious: It leads
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.
> 
> 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
> 
> 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.

OK, I'll do that.

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

I'll do that too.

Bruno