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

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> This is almost becoming funny.  You did not even look at the file I
> attached to my previous post.  Of course, why would you do so, with a
> guiding principle that everyone is wrong?

I did, it's an error I've seen numerous times.

> Looking at that file would have saved yourself from throwing more
> nonsense in this discussion.  You would have seen that the error has
> nothing to do with 4-byte longs.  The error is that Sun C 5.8 does not
> recognize the "alignas" keyword, which is a C11 construct that was
> introduced unconditionally in Emacs by e32a579975 in July 2012.  It
> was made conditional only ten years later, by 1e2bc1bbf4 in December
> 2021 (to support builds with older version of TCC).

[...]

> Given that there has been a grand total of zero bug reports from Sun C
> 5.8 users about this, we can safely conclude that nobody compiled
> Emacs with Sun C 5.8 between July 2012 and December 2021, that is,
> Emacs 25 up to and including 28.
>
> Both "alignas" and "typeof" are supported by Sun 5.9, released two
> years after Sun C 5.8, in 2007.

alignas is and was only required to support builds where LSB tags are
required.  Such tags are not necessary on the Unix systems which support
Sun C 5.9, as there `malloc' does not return values with an arbitrary
offset in the name of security or require hacking machine and system
headers to define the offset of the program's data segment.

Furthermore, at the time of alignof's introduction, lisp.h defined it to
an empty macro if Gnulib's stdalign module could not provide a
substitute, so by no means was it ever invoked unconditionally.  A
series of oversights starting from 2015 gave rise to that situation,
which were notably revealed by testing and subsequently corrected.

Lastly, each of these oversights attended changes made on solid grounds,
such as crashes in other obscure builds (e.g. the 32-bit Windows build
with wide integers and specific versions of GCC).  If anything, this
speaks against sacrificing portability on the basis of categorical
assumptions that certain non-standard constructs are always available.

> These patches were released two years after Sun C 5.9, which was
> freely downloadable, at no charge.  IOW, in 2009, an up to date
> Solaris system would have provided Sun C 5.9 for already two years, or
> even Sun C 5.10, which was released that year.  In 2024, an up to date
> Solaris 10 system provides Sun C 5.11 or above.

Unpatched versions of Sun C are not suitable for compiling Emacs.  5.9
through 5.12, for example, miscompile Fassoc, which prevents a 64-bit
window-system build from loading x-win.el.

Here I take exception to your choice of terminology.  An up-to-date
system is one where all patches to installed software have been present,
not a system with their newest and often incompatible versions.

> Your claim has now narrowed down to the following: Sun C 5.8, but only
> with some patches, and only on 64-bit platforms, can produce a working
> Emacs 29 build.

This was my claim from the outset, because that was the combination of
Sun C and system configuration on which I tested Emacs.  It has not
become any more or less defined.

> I will not waste more of my time to check that claim in detail, but
> FTR I seriously doubt it is: my attempt at building Emacs 29 failed
> with '"alloc.c", line 692: type of struct member "__b" can not be
> derived from structure with flexible array member', for which the
> remedy is, according to a Google search, "upgrade your tools to Oracle
> Solaris Studio (previously Sun Studio) 12 [that is, Sun C 5.9] or
> something newer".

That is an implementation choice in early versions of C 5.8, addressed
either by later patches or certain versions of Sun Studio Express.  My
site's KB (in relation to a physics simulation package rather than
Emacs) suggests configuring with:

  ac_cv_c_flexmember=no

but it was not necessary for me.

> But, even assuming that your claim is true, given that no-one compiled
> Emacs 25-28 with Sun C 5.8 in more than ten years, no-one suddenly
> needs to compile Emacs 29 with that compiler in 2024.  Claiming the
> opposite is beyond absurd.

"Need" is beside the point: if a compiler exists and is not downright
broken, Emacs should not knowingly cease to support it, especially not
over the objections of someone who is willing to test and continue
supporting it.

> That link is irrelevant: it's about Gnulib, which is a different
> project with different constraints and different goals.

Gnulib shares its portability considerations with our project and the
GNU project as a whole.  If anything, our standards are significantly
more charitable than are Gnulib's, with regard to Microsoft operating
systems.