bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU coding standards


From: Arsen Arsenović
Subject: Re: GNU coding standards
Date: Sat, 19 Oct 2024 20:44:18 +0200

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > , however, C23 has entirely removed unprototyped
>   > +definitions,
>
> We should never cite external standards to justify our decisions.  We
> pay attention to those standards because they are part of the
> situation in which we release software, but we do not grant them
> autority The section "Non-GNU Standards" in the GNU Coding Standards
> explains our attitude towards standards.

I have read and understood this section long ago.

> In particular, if a standard we generally follow removes a feature,
> that is no direct reason for us to remove it.

And we did not.  GCC still supports this feature.  To my awareness,
we've no plans to stop doing so (or reason to stop doing so currently).

> This issue is not about whether GNU should support that feature.  This
> issue is about whether it is useful to recommend that programmers
> write code to use the feature.
>
> We base such decisions on the practicalities of compatibility.  The
> fact that C23 eliminated K&R syntax for function definiions has
> changed those practicalities, by leading the developers of some
> compilers to eliminate that feature.  How foolish of them to cause
> gratuitous code-rot -- but that judgment does not alter the facts of
> what they have done.  Those facts affect what is useful or not useful
> in the code of GNU packages.

I propose that it is no longer useful to do so, with this features
removal from C23 being a 'final nail in the coffin' rather than the
explicit reason.  I am open to swapping the two reasons from:

  function definition, however, C23 has entirely removed unprototyped
  definitions, and compilers that do not support the standard style of
  function definition are few and far between.

... to:

  function definition, however, compilers that do not support the
  standard style of function definition are few and far between, and C23
  has entirely removed unprototyped definitions.

This prioritizes the practical aspect.

I do, however, think that this specific point of consideration is one
worth keeping, as there's been a positive development since the times
when these standards were new and not widely supported: GNU developers
seat the standard committees in question, and these standards have
become quite universal.

The "scene" nowadays is far more aligned with ISO C, and ISO C++ (and
those are far more aligned with GCC) so I wager there's quite little
portability lost by following their decisions, compared to portability
loss, and surprise caused by not doing so.

For instance, I as compilers start building C23 code by default, code
implementing this portability measure will get diagnosed (via a warning
in the case of GCC).  Of course, with GCC, building can be restored
quite simply via the -std switch, or via -Wno-old-style-definitions, but
even that does not seem worth it, since I am not aware of any system
which sees significant likelihood of using new GNU (or otherwise)
software where standard function definitions are not supported.

> That is the reason why we should make this change, and that is what we
> should cite as a reason.

-- 
Arsen Arsenović

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]