Re: master 37889523278: Add new `swap` macro and use it

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: gregory@heytings.org,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 14 Jan 2024 16:05:26 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Instead of reverting, the swap macro could have used __typeof__ where
> > typeof is not available.  This has been pointed out several times
> > already, so I don't understand why you keep raising this non-issue.
> 
> __typeof__ is not Standard C, and our declared objective is to be
> "portable to C99 or later".

No, that's not our declared objective.  The declared objective is to
be able to compile Emacs on supported platforms, and requiring C99 is
the means to that end, which makes the maintenance burden lighter.
However, C99 requirement is not relevant to C extensions such as this
one, and the requirement of C99 is not a dogma.

> Invoking non-standard syntactic features
> such as __typeof__ without a check is an issue in itself, regardless of
> the number of systems it affects, not least when it is not invoked from
> code that can reasonably be expected to only compile on machines with
> well-established compilers (i.e. w32*.c, android*.c), but from code that
> must compile everywhere.

We are pragmatic in the extensions of C we use: we use standard
features where they are available, otherwise we use extensions.  Since
we know that __typeof__ is supported by the compiler of the system
where you had problems with typeof, we can use it without fear.  If
you are saying that a configure-time test for typeof and __typeof__ is
better, I tend to agree (patches welcome), but the advantage is
relatively minor when there's only one compiler we know of and care
about that doesn't support typeof.

> Further proving my point, neither variant of typeof compiles with Sun C
> 5.8, a C99 compiler that does presently produce working Emacs builds.

Which system configuration uses this compiler?  When was that compiler
released?  Are there newer versions of that compiler that do support
one of these keywords?

Those are the questions we should ask before we conclude that typeof
or its variants cannot be used.  It isn't a dogma, and wee shouldn't
give up so easily, let alone summarily reject changes based on such
weak basis.

> > The only breakage we know of was with a compiler that does support
> > __typeof__, AFAIU, so again: why do you keep insisting on your
> > absolute rejection of the macro, when all the real problems have been
> > addressed?
> 
> If Gnulib doesn't require __typeof__, why should we?

Because we are not Gnulib, and our goals are very different from those
of Gnulib.

> Generally speaking, Emacs is portable to more systems and compilers
> than Gnulib officially is; departing from this policy for no good
> reason will frustrate users and future porting efforts alike.

But we do have a good reason.