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

[Gregory Heytings]

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

You did not, otherwise you would not have explained the build failure with 
something that had no relationship whatsoever with it.

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

All that is irrelevant in the matter at hand.

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

That's wrong.  Again you are just ignoring the information I gave you. 
So I'll say it again: alignas, a C11 feature, was introduced 
unconditionally in Emacs by e32a579975 in July 2012, and it was made 
conditional only ten years later, by 1e2bc1bbf4 in December 2021 (to 
support builds with older version of TCC).  Without the "# define 
alignas(a)" line in lisp.h, which was added by 1e2bc1bbf4 and was 
therefore not present in Emacs 25-28, Sun C 5.8 fails to compile Emacs 29 
in the same way it fails to compile Emacs 25-28.

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

All that is irrelevant to the matter at hand.

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

Absolutely not.  Your claim is and was that Sun C 5.8 produces working 
Emacs builds, and in the post to which I was replying, you said:

The GCC build farm, Paul Eggert, and several other Emacs and Gnulib 
developers have and routinely test on up-to-date Solaris 10 systems with 
various versions of Sun Studio.

followed by a link to a post in which Sun C 5.8 was mentioned.  I don't 
know about Gnulib, but it is clear that Emacs was not at all "routinely" 
tested with Sun C 5.8, given that the build failed early between July 2012 
and December 2021, with zero bug reports about that failure, and given 
that it still fails today, albeit later, again with zero bug reports about 
that failure.

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

Sorry, enough is enough.  As I said, I simply refuse to waste more of my 
time to determine under which circumstances and with which undocumented 
configuration options, if any, a proprietary compiler that has been EOL'd 
almost ten years ago could perhaps create a working Emacs build for a very 
specific platform that hardly anybody uses.  My attempt, with a standard 
"make", failed as described above, and the reason of that failure is 
simply that Sun C 5.8 does not implement alignof, which is used in Emacs 
29 and is, like alignas and typeof, available in Sun C 5.9 and later 
compilers.

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

You've already been told, by Eli, that "our goals are very different from 
those of Gnulib".  So what's the point of saying this again?