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

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> branch: master
> commit 37889523278fe65733938fb11c3701898309961c
> Author: Stefan Kangas <stefankangas@gmail.com>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
>     Add new `swap` macro and use it
>     
>     A `swap` macro prevents programming errors and is more concise.
>     It is a natural addition to our existing `min` and `max` macros.

It's well known that a generic "swap" macro is impossible to express in
Standard C for lack of a standard "typeof"-like expression.  To
compensate for this limitation, the macro must accept an argument
identifying the type of the field where the temporary value is saved,
which is more trouble than it's worth and reintroduces the type
conversion problems such macros are intended to prevent.

Neither typeof nor __typeof__ are portable by our standards, the latter
being an extension compatible with the Standard enabled when GCC is
configured to obey the standard to the letter, while the former is a
keyword enabled in other situations.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 06 Jan 2024 15:39:11 +0800
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > branch: master
> > commit 37889523278fe65733938fb11c3701898309961c
> > Author: Stefan Kangas <stefankangas@gmail.com>
> > Commit: Stefan Kangas <stefankangas@gmail.com>
> >
> >     Add new `swap` macro and use it
> >     
> >     A `swap` macro prevents programming errors and is more concise.
> >     It is a natural addition to our existing `min` and `max` macros.
> 
> It's well known that a generic "swap" macro is impossible to express in
> Standard C for lack of a standard "typeof"-like expression.  To
> compensate for this limitation, the macro must accept an argument
> identifying the type of the field where the temporary value is saved,
> which is more trouble than it's worth and reintroduces the type
> conversion problems such macros are intended to prevent.
> 
> Neither typeof nor __typeof__ are portable by our standards, the latter
> being an extension compatible with the Standard enabled when GCC is
> configured to obey the standard to the letter, while the former is a
> keyword enabled in other situations.

Regardless of portability issues, I think the macro should be called
SWAP, upper-case, to avoid clashes with functions.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Regardless of portability issues, I think the macro should be called
> SWAP, upper-case, to avoid clashes with functions.

I reverted the change for being impossible to build with compilers
besides GCC and others implementing its extensions.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Regardless of portability issues, I think the macro should be called
>> SWAP, upper-case, to avoid clashes with functions.
>
> I reverted the change for being impossible to build with compilers
> besides GCC and others implementing its extensions.

Thanks, but whether or not that revert was justified, please stop
reverting patches before people have time to react, or while discussions
are still ongoing.  It is perceived as uncollaborative at best.

If you need to compile the latest changes on master on some unusual
compiler this very morning, you can revert it locally.  So there is no
rush here.

Premature reverts only serve to mess up our git history, in case we need
to re-apply the changes later, and is just a bad way of doing things.

Please see the patch I sent separately, and let me know if you have any
thoughts.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Thanks, but whether or not that revert was justified, please stop
> reverting patches before people have time to react, or while discussions
> are still ongoing.  It is perceived as uncollaborative at best.

When Mattias last proposed a policy of reverting changes which break the
build at once, there were essentially no objections.  I think we should
definitely value a repository which builds over a repository that
cannot, merely in the interests of appearing collaborative: after all it
is possible to debate a change wherever it might be, in the repository
or elsewhere.

Thanks.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> When Mattias last proposed a policy of reverting changes which break the
> build at once, there were essentially no objections.  I think we should
> definitely value a repository which builds over a repository that
> cannot, merely in the interests of appearing collaborative: after all it
> is possible to debate a change wherever it might be, in the repository
> or elsewhere.

OK, I think I see where you are coming from.  My interpretation of that
discussion is a bit different.

To my mind, that discussion was mainly about what people use in their
day-to-day hacking on Emacs, because that's where the disruption happens
when the build is broken even if it's only broken briefly.

I think that's mostly GCC (and clang to some extent) on GNU/Linux,
macOS, MS-Windows and perhaps even a few of the *BSDs.  AFAIK, the
commit didn't affect any of those, but only more unusual ones that none
of our regulars use.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> OK, I think I see where you are coming from.  My interpretation of that
> discussion is a bit different.
>
> To my mind, that discussion was mainly about what people use in their
> day-to-day hacking on Emacs, because that's where the disruption happens
> when the build is broken even if it's only broken briefly.

There's no reason to hesitate before reverting a minor change that
neither provides new features nor modifies internal details in a manner
beneficial to users of systems it doesn't affect.

In such instances, the number of users affected is not a valid
consideration, because reverting the change will not be detrimental to
any of them regardless of whether they were affected.

Lastly, this particular change's existence invites more references to
the macro it adds that will interfere with reverting it in the future;
this also goes for other changes providing new interfaces, or modifying
existing ones.  Time is thus of the essence.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 06 Jan 2024 21:13:52 +0800
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > OK, I think I see where you are coming from.  My interpretation of that
> > discussion is a bit different.
> >
> > To my mind, that discussion was mainly about what people use in their
> > day-to-day hacking on Emacs, because that's where the disruption happens
> > when the build is broken even if it's only broken briefly.
> 
> There's no reason to hesitate before reverting a minor change that
> neither provides new features nor modifies internal details in a manner
> beneficial to users of systems it doesn't affect.

Please in the future only revert commits by others without discussion
if they either completely break a build or are obviously wrong.
Everything else should be discussed first.

Did Stefan's change break some build?  If so, which build became
broken and why?

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Please in the future only revert commits by others without discussion
> if they either completely break a build or are obviously wrong.
> Everything else should be discussed first.

There's no need to mention "in the future", because I have never done so
in the past :-)

> Did Stefan's change break some build?  If so, which build became
> broken and why?

All builds using C compilers that don't support typeof, which is an
extension provided by GCC.  In my case, the compiler was Sun C 5.12,
where __typeof__ is available but typeof is not (by default).

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 06 Jan 2024 22:41:40 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please in the future only revert commits by others without discussion
> > if they either completely break a build or are obviously wrong.
> > Everything else should be discussed first.
> 
> There's no need to mention "in the future", because I have never done so
> in the past :-)

I can only try to affect the future, thus "in the future".

> > Did Stefan's change break some build?  If so, which build became
> > broken and why?
> 
> All builds using C compilers that don't support typeof, which is an
> extension provided by GCC.  In my case, the compiler was Sun C 5.12,
> where __typeof__ is available but typeof is not (by default).

Then you could have easily fixed the change instead of reverting it,
right?  Why didn't you?

My opinion still is that reverting without discussion should be
reserved only to very extreme situations, where fixing the problem is
not easy, and the damage from the problem is serious.  I hope others
will behave according to that.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Then you could have easily fixed the change instead of reverting it,
> right?  Why didn't you?

Because the change cannot be fixed in such a way that all affected
systems will correctly build Emacs, and is impossible to implement in C.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Then you could have easily fixed the change instead of reverting it,
>> right?  Why didn't you?
>
> Because the change cannot be fixed in such a way that all affected
> systems will correctly build Emacs, and is impossible to implement in C.

That is a serious objection if it is true.  But nothing approaching that
has been shown to be true so far, not in this thread at any rate.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> That is a serious objection if it is true.  But nothing approaching that
> has been shown to be true so far, not in this thread at any rate.

How is that so?  I and Andreas have both demonstrated that in our
respective replies in this thread.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 07 Jan 2024 15:50:37 +0800
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > That is a serious objection if it is true.  But nothing approaching that
> > has been shown to be true so far, not in this thread at any rate.
> 
> How is that so?  I and Andreas have both demonstrated that in our
> respective replies in this thread.

I don't think that was demonstrated, but even if it has been, whether
the change is so completely wrong based on the arguments is not your
decision to make.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> That is a serious objection if it is true.  But nothing approaching that
>> has been shown to be true so far, not in this thread at any rate.
>
> How is that so?  I and Andreas have both demonstrated that in our
> respective replies in this thread.

The objections I have seen are:

1. "__tmp as a reserved identifier might clash with future
   implementations"

   This is true and can be fixed by renaming it.

2. "the first argument can easily become out of date without notice"

    This is true, but of course only when _GL_HAVE___TYPEOF__.

    When !_GL_HAVE___TYPEOF__,

        swap (T, x, y);

    is subject to the same basic type errors as

        T tmp = x; x = y; y = tmp;

    If that is not workable, we could, as a last resort, just forego
    using typeof altogether.  But at that point, the macro is reduced to
    be mostly aesthetic.

So no, I don't currently see any evidence for the claims that this
"cannot be fixed" or is "impossible to implement in C".  If there is any
substance to that, you will probably have to explain it again.

Now, as I have already explained, the macro is certainly less
subjectively appealing if we have to manually write out the type every
time.  In my view it is still a bit better, since we get both more
readable code and additional safety on our main targets.  (Note that we
don't currently use -Wconversion in Emacs.)

I'm still open to hearing people's opinion about this, of course.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> 2. "the first argument can easily become out of date without notice"
>
>     This is true, but of course only when _GL_HAVE___TYPEOF__.
>
>     When !_GL_HAVE___TYPEOF__,
>
>         swap (T, x, y);
>
>     is subject to the same basic type errors as
>
>         T tmp = x; x = y; y = tmp;
>
>     If that is not workable, we could, as a last resort, just forego
>     using typeof altogether.  But at that point, the macro is reduced to
>     be mostly aesthetic.

There are no "basic type errors" inherent in this statement.  In most
instances where the type of a variable is modified, it is from one
integer type to another (e.g. long to ptrdiff_t), which means
inconsistencies between the type in the swap statement and the values
being swapped might result in truncation on compilers where __typeof__
is absent.  As they do not emit diagnostics in response to such errors,
bugs so introduced won't appear until the erroneous code is in fact
executed and the values involved are sufficiently large that truncation
produces a visible malfunction; worse yet, such bugs cannot be
discovered by developers using GCC.

> So no, I don't currently see any evidence for the claims that this
> "cannot be fixed" or is "impossible to implement in C".  If there is any
> substance to that, you will probably have to explain it again.

This has been axiomatic for eons.  From the comp.lang.c FAQ:

10.3: How can I write a generic macro to swap two values?

A: There is no good answer to this question.  If the values are
integers, a well-known trick using exclusive-OR could perhaps be used,
but it will not work for floating-point values or pointers, or if the
two values are the same variable.  (See questions 3.3b and 20.15c.)  If
the macro is intended to be used on values of arbitrary type (the usual
goal), it cannot use a temporary, since it does not know what type of
temporary it needs (and would have a hard time picking a name for it if
it did), and standard C does not provide a typeof operator.

The best all-around solution is probably to forget about using a macro,
unless you're willing to pass in the type as a third argument.

> Now, as I have already explained, the macro is certainly less
> subjectively appealing if we have to manually write out the type every
> time.  In my view it is still a bit better, since we get both more
> readable code and additional safety on our main targets.  (Note that we
> don't currently use -Wconversion in Emacs.)

Never in my life have I heard the statements for swapping two variables
characterized as "insufficiently readable", and the GNU Coding Standards
discourage programming for -Wconversion, with good reason: for each
potential error it might detect, there are numerous more assignments
where truncation is harmless or even correct, and ironically it is
inserting the casts required to pacify the linter which tends to degrade
the soundness and cosmetics of the code in question.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 07 Jan 2024 18:36:07 +0800
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > 2. "the first argument can easily become out of date without notice"
> >
> >     This is true, but of course only when _GL_HAVE___TYPEOF__.
> >
> >     When !_GL_HAVE___TYPEOF__,
> >
> >         swap (T, x, y);
> >
> >     is subject to the same basic type errors as
> >
> >         T tmp = x; x = y; y = tmp;
> >
> >     If that is not workable, we could, as a last resort, just forego
> >     using typeof altogether.  But at that point, the macro is reduced to
> >     be mostly aesthetic.
> 
> There are no "basic type errors" inherent in this statement.  In most
> instances where the type of a variable is modified, it is from one
> integer type to another (e.g. long to ptrdiff_t), which means
> inconsistencies between the type in the swap statement and the values
> being swapped might result in truncation on compilers where __typeof__
> is absent.  As they do not emit diagnostics in response to such errors,
> bugs so introduced won't appear until the erroneous code is in fact
> executed and the values involved are sufficiently large that truncation
> produces a visible malfunction; worse yet, such bugs cannot be
> discovered by developers using GCC.

Please raise these issues with the Gnulib folks, not here.  Meanwhile,
what's good enough for Gnulib should be good enough for us.

> Never in my life have I heard the statements for swapping two variables
> characterized as "insufficiently readable"

With all due respect, if you don't want your own stylistic preferences
to be questioned, please don't question those of others.  Let's all
respect the preferences of each other, okay?

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Please raise these issues with the Gnulib folks, not here.  Meanwhile,
> what's good enough for Gnulib should be good enough for us.

Stefan's patch doesn't replicate any choices made by Gnulib besides the
test for __typeof__'s presence, so what Gnulib does is beside the point.

The problem at hand is that we should not define macros which behave in
such drastically different manners across compilers subject to the
presence of __typeof__, much less macros whose erroneous invocations can
only be detected in a small portion of the configurations Emacs is built
in, and even then not without rigorous testing.

>> Never in my life have I heard the statements for swapping two variables
>> characterized as "insufficiently readable"
>
> With all due respect, if you don't want your own stylistic preferences
> to be questioned, please don't question those of others.  Let's all
> respect the preferences of each other, okay?

OK, but "swap" macros are likewise personal stylistic preferences, and
ones defective for significant and widely-recognized technical reasons
at that.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 07 Jan 2024 19:53:02 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please raise these issues with the Gnulib folks, not here.  Meanwhile,
> > what's good enough for Gnulib should be good enough for us.
> 
> Stefan's patch doesn't replicate any choices made by Gnulib besides the
> test for __typeof__'s presence, so what Gnulib does is beside the point.
> 
> The problem at hand is that we should not define macros which behave in
> such drastically different manners across compilers subject to the
> presence of __typeof__, much less macros whose erroneous invocations can
> only be detected in a small portion of the configurations Emacs is built
> in, and even then not without rigorous testing.

I don't see how this disqualifies the patch.  We have other macros and
constructs that need to be used with care.

> >> Never in my life have I heard the statements for swapping two variables
> >> characterized as "insufficiently readable"
> >
> > With all due respect, if you don't want your own stylistic preferences
> > to be questioned, please don't question those of others.  Let's all
> > respect the preferences of each other, okay?
> 
> OK, but "swap" macros are likewise personal stylistic preferences, and
> ones defective for significant and widely-recognized technical reasons
> at that.

And I ask you to respect Stefan's stylistic preferences here.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

>> So no, I don't currently see any evidence for the claims that this
>> "cannot be fixed" or is "impossible to implement in C".  If there is any
>> substance to that, you will probably have to explain it again.
>
> This has been axiomatic for eons.  From the comp.lang.c FAQ:

If you insist on using the word "axiomatic", which I frankly think makes
no sense here, surely that's only relevant to things proscribed by the C
standard.

Anyways, the comp.lang.c FAQ entry you quoted here does not discuss the
typeof operator.  That has been changed in more recent versions.

>> Now, as I have already explained, the macro is certainly less
>> subjectively appealing if we have to manually write out the type every
>> time.  In my view it is still a bit better, since we get both more
>> readable code and additional safety on our main targets.  (Note that we
>> don't currently use -Wconversion in Emacs.)
>
> Never in my life have I heard the statements for swapping two variables
> characterized as "insufficiently readable",
                   ^^^^^^^^^^^^^^^^^^^^^^^^^

Quote marks are inappropriate here, because those were not my words.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Anyways, the comp.lang.c FAQ entry you quoted here does not discuss the
> typeof operator.  That has been changed in more recent versions.

It makes unambiguous reference to the bearing of typeof:

10.3: How can I write a generic macro to swap two values?

A: There is no good answer to this question.  If the values are
integers, a well-known trick using exclusive-OR could perhaps be used,
but it will not work for floating-point values or pointers, or if the
two values are the same variable.  (See questions 3.3b and 20.15c.)  If
the macro is intended to be used on values of arbitrary type (the usual
goal), it cannot use a temporary, since it does not know what type of
temporary it needs (and would have a hard time picking a name for it if
it did), and standard C does not provide a typeof operator.
                                           ------

Nothing in this respect has changed since this was written: Standard C
won't provide a typeof operator until later this year, and it will be
decades before it will be universally available to programs.  For that
matter, what are we arguing over?  Is it really this hard to agree on
the two facts that typeof is not portable, by our standards of
portability (C99, and various operating systems), and macros with which
invocation errors cannot be detected except on a handful of
little-tested systems are liable to produce many such errors, much like
GCPRO once did?

Both statements have been accepted wisdom where C development is
concerned for quite a while now, and we have direct experience with the
latter, which was reason enough to remove the problematic macro.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 07 Jan 2024 09:39:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then you could have easily fixed the change instead of reverting it,
> > right?  Why didn't you?
> 
> Because the change cannot be fixed in such a way that all affected
> systems will correctly build Emacs, and is impossible to implement in C.

Sorry, I don't understand.  AFAICT, something like

 #if SUN
 # define TYPEOF __typeof__
 #else
 # define TYPEOF __typeof
 #endif

would have solved the problem of the compiler with which you had the
problem.  If not, why not?  If the above would solve the problem, why
didn't you fix the commit that way, instead of reverting?

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

[Gregory Heytings]

>
> Did Stefan's change break some build?  If so, which build became broken 
> and why?
>

FYI, Stefan's change did not break any build.  "typeof" is supported by 
all compilers with which Emacs can be built, either with the keyword 
"typeof" or with the keyword "__typeof__".  The only notable compiler that 
does not support "typeof" is MSVC, with which Emacs cannot be built.

"typeof" will, moreover, officially become part of Standard C in a few 
weeks.  In doing so, the standard committee did not add something new to 
the language, but instead codified existing practice.  You can see this in 
the rationale for that change [1], which says:

"Every implementation in existence since C89 has an implementation of 
typeof. Some compilers (GCC, Clang, EDG, tcc, and many, many more) expose 
this with the implementation extension typeof. [...] This feature is the 
most "existing practice"-iest feature to be proposed to the C Standard, 
possibly in the entire history of the C standard. The feature was also 
mentioned in an "extension round up" paper that went over the state of C 
Extensions in 2007. typeof was also considered an important extension 
during the discussion of that paper, but nobody brought forth the paper 
previously to make it a reality."

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2619.htm

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

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

> FYI, Stefan's change did not break any build.  "typeof" is supported by
> all compilers with which Emacs can be built, either with the keyword
> "typeof" or with the keyword "__typeof__".  The only notable compiler that
> does not support "typeof" is MSVC, with which Emacs cannot be built.

Thanks, that's encouraging.  This implies that we wouldn't need to state
the type explicitly, as we can always rely on typeof or __typeof__.

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

[Richard Stallman]

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

  > FYI, Stefan's change did not break any build.  "typeof" is supported by 
  > all compilers with which Emacs can be built, either with the keyword 
  > "typeof" or with the keyword "__typeof__".  The only notable compiler that 
  > does not support "typeof" is MSVC, with which Emacs cannot be built.

I belkeve I was the first to implement a typeof construct in C.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> FYI, Stefan's change did not break any build.  "typeof" is supported
> by all compilers with which Emacs can be built, either with the
> keyword "typeof" or with the keyword "__typeof__".  The only notable
> compiler that does not support "typeof" is MSVC, with which Emacs
> cannot be built.

Stefan's change (which I reverted) did not use __typeof__.

> "Every implementation in existence since C89 has an implementation of
> typeof. Some compilers (GCC, Clang, EDG, tcc, and many, many more)
> expose this with the implementation extension typeof. [...] This
> feature is the most "existing practice"-iest feature to be proposed to
> the C Standard, possibly in the entire history of the C standard. The
> feature was also mentioned in an "extension round up" paper that went
> over the state of C Extensions in 2007. typeof was also considered an
> important extension during the discussion of that paper, but nobody
> brought forth the paper previously to make it a reality."

Considering that EDG and GNU/Linux compilers are the only compilers you
have named as examples, this list is nowhere near sufficient to prove
that "typeof" does not break any build.  Which is a very presumptuous
statement whatever the length of your list, when a build breaking was in
fact the reason for this change...

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 14 Jan 2024 13:14:47 +0800
> 
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > FYI, Stefan's change did not break any build.  "typeof" is supported
> > by all compilers with which Emacs can be built, either with the
> > keyword "typeof" or with the keyword "__typeof__".  The only notable
> > compiler that does not support "typeof" is MSVC, with which Emacs
> > cannot be built.
> 
> Stefan's change (which I reverted) did not use __typeof__.

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.

> > "Every implementation in existence since C89 has an implementation of
> > typeof. Some compilers (GCC, Clang, EDG, tcc, and many, many more)
> > expose this with the implementation extension typeof. [...] This
> > feature is the most "existing practice"-iest feature to be proposed to
> > the C Standard, possibly in the entire history of the C standard. The
> > feature was also mentioned in an "extension round up" paper that went
> > over the state of C Extensions in 2007. typeof was also considered an
> > important extension during the discussion of that paper, but nobody
> > brought forth the paper previously to make it a reality."
> 
> Considering that EDG and GNU/Linux compilers are the only compilers you
> have named as examples, this list is nowhere near sufficient to prove
> that "typeof" does not break any build.  Which is a very presumptuous
> statement whatever the length of your list, when a build breaking was in
> fact the reason for this change...

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?

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

[Po Lu]

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

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

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

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

[Eli Zaretskii]

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

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

[Gregory Heytings]

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

Sun C 5.8 is part of Sun Studio 11, which was released in 2005.  Sun 
Studio 11 is an (optional) extension package for Solaris 10 / SunOS 
5.10... on which GCC (3.4.3) is installed by default.

Sun C 5.9, part of Sun Studio 12 (which is likewise an optional extension 
package for that same operating system), released in 2007, supports the 
typeof operator.

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

[Eli Zaretskii]

> Date: Mon, 15 Jan 2024 01:32:38 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Po Lu <luangruo@yahoo.com>, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> 
> >> 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?
> >
> 
> Sun C 5.8 is part of Sun Studio 11, which was released in 2005.  Sun 
> Studio 11 is an (optional) extension package for Solaris 10 / SunOS 
> 5.10... on which GCC (3.4.3) is installed by default.
> 
> Sun C 5.9, part of Sun Studio 12 (which is likewise an optional extension 
> package for that same operating system), released in 2007, supports the 
> typeof operator.

Thanks.  Given this information, I don't see why we should be bothered
with the deficiencies of Sun C 5.8.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 15 Jan 2024 01:32:38 +0000
>> From: Gregory Heytings <gregory@heytings.org>
>> cc: Po Lu <luangruo@yahoo.com>, stefankangas@gmail.com, emacs-devel@gnu.org
>> 
>> 
>> >> 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?
>> >
>> 
>> Sun C 5.8 is part of Sun Studio 11, which was released in 2005.  Sun 
>> Studio 11 is an (optional) extension package for Solaris 10 / SunOS 
>> 5.10... on which GCC (3.4.3) is installed by default.
>> 
>> Sun C 5.9, part of Sun Studio 12 (which is likewise an optional extension 
>> package for that same operating system), released in 2007, supports the 
>> typeof operator.
>
> Thanks.  Given this information, I don't see why we should be bothered
> with the deficiencies of Sun C 5.8.

For the same reason we bother with the deficiencies of GCC 3.4.3 and
other C compilers and OSes.  It is not enough that Emacs work on some
combination of supported system and compiler, it must work on _all_
combinations of C compiler and supported system, provided that the C
compiler is reasonable, for which we have a definition provided by the
C99 Standard.

No doubt Emacs has failed to fulfill this strict (albeit not extreme)
measure of portability on occasion, but such instances are far and few
between, and their causes we promptly fix after being apprised of them.
Between that and the fact that we have never willfully undermined the
quality of our code in this respect, Emacs has thus far held up to its
side of the bargain remarkably well.  My point being that a `swap'
macro, which is also generally discountenanced by C programmers, is not
sufficiently compelling a reason to depart from doing so.

This practice of ours is so well established as to justify a mention in
the GNU Coding Standards identifying Emacs by name.  (standards)Using
Extensions:

  An exception to this rule are the large, established programs (such as
  Emacs) which run on a great variety of systems.  Using GNU extensions
  in such programs would make many users unhappy, so we don't do that.

Before you is one user who would be unhappy in such an event!

FWIW:

Sun Studio 5.8 and 5.12 were once standard on systems at my workplace,
but we have since moved to a different C compiler that has rendered both
and GCC redundant, and does not implement "__typeof__" in its default
mode of operation, despite being usually configured for compatibility
with Sun C.  I will try to establish if its defaults are capable of
compiling Emacs tomorrow.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Mon, 15 Jan 2024 21:56:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Sun C 5.8 is part of Sun Studio 11, which was released in 2005.  Sun 
> >> Studio 11 is an (optional) extension package for Solaris 10 / SunOS 
> >> 5.10... on which GCC (3.4.3) is installed by default.
> >> 
> >> Sun C 5.9, part of Sun Studio 12 (which is likewise an optional extension 
> >> package for that same operating system), released in 2007, supports the 
> >> typeof operator.
> >
> > Thanks.  Given this information, I don't see why we should be bothered
> > with the deficiencies of Sun C 5.8.
> 
> For the same reason we bother with the deficiencies of GCC 3.4.3 and
> other C compilers and OSes.

AFAIK, we care about GCC 3.4.3 only for the MSDOS build, and only
because the MSDOS port cannot be built at all with any later version
of GCC.  And only for some value of "care": building Emacs with that
old version spews gobs of bogus warnings about "condition being true
due to limited data size", and we ignore that.

I fail to see how this is similar to the issue here.

> It is not enough that Emacs work on some combination of supported
> system and compiler, it must work on _all_ combinations of C
> compiler and supported system, provided that the C compiler is
> reasonable, for which we have a definition provided by the C99
> Standard.

No, that's not the goal.  We only support versions of the compilers
that are good enough for us.  So if a platform has a newer compiler
that will do, and that compiler is not too new and hard to obtain,
that is enough to not bother with supporting a much older version of
that compiler on that platform.  Especially wrt a proprietary compiler
on a proprietary OS.

> This practice of ours is so well established as to justify a mention in
> the GNU Coding Standards identifying Emacs by name.  (standards)Using
> Extensions:
> 
>   An exception to this rule are the large, established programs (such as
>   Emacs) which run on a great variety of systems.  Using GNU extensions
>   in such programs would make many users unhappy, so we don't do that.
> 
> Before you is one user who would be unhappy in such an event!

This is not a dogma, and doesn't have to be applied religiously in
every single instance of every single extension.  The above just hints
to people not to take Emacs as a counter-argument to the rest of the
advice in that section.

> Sun Studio 5.8 and 5.12 were once standard on systems at my workplace,
> but we have since moved to a different C compiler that has rendered both
> and GCC redundant, and does not implement "__typeof__" in its default
> mode of operation, despite being usually configured for compatibility
> with Sun C.  I will try to establish if its defaults are capable of
> compiling Emacs tomorrow.

If this is just to convince me not to install swap or some of its
variants, then please don't waste your time: I've already made the
decision, and it will not change because you find some compiler that
doesn't support typeof in any shape.

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

[Gregory Heytings]

>>>> 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?
>>
>> Sun C 5.8 is part of Sun Studio 11, which was released in 2005.  Sun 
>> Studio 11 is an (optional) extension package for Solaris 10 / SunOS 
>> 5.10... on which GCC (3.4.3) is installed by default.
>>
>> Sun C 5.9, part of Sun Studio 12 (which is likewise an optional 
>> extension package for that same operating system), released in 2007, 
>> supports the typeof operator.
>
> Thanks.  Given this information, I don't see why we should be bothered 
> with the deficiencies of Sun C 5.8.
>

FYI, the claim "Sun C 5.8, a C99 compiler that does presently produce 
working Emacs builds" is pure fantasy, aka fabricated evidence.  I had 
some free time today, I digged in my archives, and found a copy of Solaris 
10 and Sun Studio 11, which I installed in a VM.  The last Emacs version 
for which Sun C 5.8 produces a working Emacs build is... Emacs 24.

Much ado about nothing.  Somehow, I'm not surprised.

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

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> FYI, the claim "Sun C 5.8, a C99 compiler that does presently produce
> working Emacs builds" is pure fantasy, aka fabricated evidence.  I had
> some free time today, I digged in my archives, and found a copy of
> Solaris 10 and Sun Studio 11, which I installed in a VM.  The last
> Emacs version for which Sun C 5.8 produces a working Emacs build
> is... Emacs 24.

Really?  What's the error, and what CPU did you install it on?

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]


>> FYI, the claim "Sun C 5.8, a C99 compiler that does presently produce 
>> working Emacs builds" is pure fantasy, aka fabricated evidence.  I had 
>> some free time today, I digged in my archives, and found a copy of 
>> Solaris 10 and Sun Studio 11, which I installed in a VM.  The last 
>> Emacs version for which Sun C 5.8 produces a working Emacs build is... 
>> Emacs 24.
>
> Really?
>

Really.

>
> What's the error
>

It's not "the error", it's "the errors".  Building Emacs 25 to 29 with the 
simplest possible configuration (--without-all --without-x) fails, and 
fails early on (while compiling dispnew.c), but the error messages are 
different in each case.  I attach those of Emacs 25.

>
> and what CPU did you install it on?
>

That would have mattered only if the compiler had produced a non-working 
build.  It cannot even create the first object file.

[-- Attachment #2: make.log --]
[-- Type: text/plain, Size: 3423 bytes --]

make -C lib all
make[1]: Entering directory `/home/greg/emacs-25.1/lib'
  GEN      byteswap.h
  GEN      dirent.h
  GEN      execinfo.h
  GEN      fcntl.h
  GEN      getopt.h
  GEN      inttypes.h
  GEN      signal.h
  GEN      stdalign.h
  GEN      stddef.h
  GEN      stdint.h
  GEN      stdio.h
  GEN      stdlib.h
  GEN      string.h
  GEN      sys/select.h
  GEN      sys/stat.h
  GEN      sys/time.h
  GEN      sys/types.h
  GEN      time.h
  GEN      unistd.h
make  all-am
make[2]: Entering directory `/home/greg/emacs-25.1/lib'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/greg/emacs-25.1/lib'
make[1]: Leaving directory `/home/greg/emacs-25.1/lib'
make -C lib-src all
make[1]: Entering directory `/home/greg/emacs-25.1/lib-src'
make -C ../lib all
make[2]: Entering directory `/home/greg/emacs-25.1/lib'
make  all-am
make[3]: Entering directory `/home/greg/emacs-25.1/lib'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/greg/emacs-25.1/lib'
make[2]: Leaving directory `/home/greg/emacs-25.1/lib'
make[1]: Leaving directory `/home/greg/emacs-25.1/lib-src'
make -C src VCSWITNESS='' all
make[1]: Entering directory `/home/greg/emacs-25.1/src'
make -C ../lib all
make[2]: Entering directory `/home/greg/emacs-25.1/lib'
make  all-am
make[3]: Entering directory `/home/greg/emacs-25.1/lib'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/greg/emacs-25.1/lib'
make[2]: Leaving directory `/home/greg/emacs-25.1/lib'
  CC       dispnew.o
"globals.h", line 926: syntax error before or at: 8
"globals.h", line 926: warning: old-style declaration or incorrect type for: lispsym
"lisp.h", line 1109: warning: argument #1 is incompatible with prototype:
        prototype: pointer to struct Lisp_Symbol {_Bool gcmarkbit :1, enum symbol_redirect {SYMBOL_FORWARDED(3), SYMBOL_LOCALIZED(2), SYMBOL_VARALIAS(1), SYMBOL_PLAINVAL(4)} redirect :3, unsigned int constant :2, unsigned int interned :2, _Bool declared_special :1, _Bool pinned :1, int name, union  {..} val, int function, int plist, pointer to struct Lisp_Symbol {..} next} : "lisp.h", line 1099
        argument : pointer to int
"dispnew.c", line 3016: syntax error before or at: 8
"dispnew.c", line 3016: identifier redefined: alignas
        current : function() returning struct Lisp_Subr {struct vectorlike_header {..} header, union  {..} function, short min_args, short max_args, pointer to const char symbol_name, pointer to const char intspec, pointer to const char doc}
        previous: function() returning struct Lisp_Symbol {_Bool gcmarkbit :1, enum symbol_redirect {SYMBOL_FORWARDED(3), SYMBOL_LOCALIZED(2), SYMBOL_VARALIAS(1), SYMBOL_PLAINVAL(4)} redirect :3, unsigned int constant :2, unsigned int interned :2, _Bool declared_special :1, _Bool pinned :1, int name, union  {..} val, int function, int plist, pointer to struct Lisp_Symbol {..} next} : "globals.h", line 926
"dispnew.c", line 3016: warning: old-style declaration or incorrect type for: Sredraw_frame
"dispnew.c", line 3016: too many initializers for scalar
"dispnew.c", line 3016: structure/union designator used on non-struct/union type
"dispnew.c", line 3022: cannot recover from previous errors
cc: acomp failed for dispnew.c
make[1]: *** [dispnew.o] Error 2
make[1]: Leaving directory `/home/greg/emacs-25.1/src'
make: *** [src] Error 2

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

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> That would have mattered only if the compiler had produced a
> non-working build.  It cannot even create the first object file.

The errors in lisp.h are caused by your building Emacs with 4-byte
longs, hence "CPU".  Emacs cannot build on Sun compilers without
`-xarch=generic64 -xc99 -D__STDC__=1', and in the case of Sun C 5.8,
patches 121015-07 (sparc) or 121016-08 (Intel), which address code
generation errors concerning bitfields.  There are no Solaris 10 32-bit
kernels available for SPARC, so it is reasonable to expect Emacs to be
built with 8-byte longs.

Considering that you downloaded Sun C from the Internet, it is probably:

$ /opt/SUNWspro/bin/cc -V

cc: Sun C 5.8 2005/10/13

that is 4 years out of date.  Install:

$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.8 Patch 121015-07 2009/04/22

with:

# smpatch -G -i 121015-07

Talk about presumption!

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Considering that you downloaded Sun C from the Internet, it is probably:
>
> $ /opt/SUNWspro/bin/cc -V
>
> cc: Sun C 5.8 2005/10/13
>
> that is 4 years out of date.  Install:
>
> $ /opt/SUNWspro/bin/cc -V
> cc: Sun C 5.8 Patch 121015-07 2009/04/22
>
> with:
>
> # smpatch -G -i 121015-07

I don't pretend to be a Solaris expert, but the above suggests that you
can upgrade software on that system.

- What's stopping users from installing Sun C 5.9?
- Which systems are we talking about, and do we have any reason to
  believe that they are in wide use in 2024?  Presumably, these machines
  were installed before 2007, when Sun C 5.9 was released.
- Finally, why can't we ask these users to run GCC?  We also don't
  support MSVC, for example, so adding another unportable compiler to
  the list doesn't sound like a disaster (especially since they can just
  upgrade to the next version).

> Talk about presumption!

Not sure what this is in reference to.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Considering that you downloaded Sun C from the Internet, it is probably:
>>
>> $ /opt/SUNWspro/bin/cc -V
>>
>> cc: Sun C 5.8 2005/10/13
>>
>> that is 4 years out of date.  Install:
>>
>> $ /opt/SUNWspro/bin/cc -V
>> cc: Sun C 5.8 Patch 121015-07 2009/04/22
>>
>> with:
>>
>> # smpatch -G -i 121015-07
>
> I don't pretend to be a Solaris expert, but the above suggests that you
> can upgrade software on that system.
>
> - What's stopping users from installing Sun C 5.9?

Patches are only provided for installed software to be _updated_.  Sun
Sun C 5.9 is not an update to 5.8 but a completely new compiler, with a
suitably new package name, separate support and update arrangements, and
the like.

> - Which systems are we talking about, and do we have any reason to
>   believe that they are in wide use in 2024?  Presumably, these machines
>   were installed before 2007, when Sun C 5.9 was released.

Sun C 5.9 is incompatible with 5.8, and users may choose to run either
compiler (as well as later releases) on Solaris 10 systems, until 2027.

> - Finally, why can't we ask these users to run GCC?  We also don't
>   support MSVC, for example, so adding another unportable compiler to
>   the list doesn't sound like a disaster (especially since they can just
>   upgrade to the next version).

AFAIU MSVC is not an ISO C99 compiler, so it's natural that we don't
support it.  The MSVC build also required its own build system and
Makefiles (see nt/configure.bat, cf. config.bat), which were already
nonfunctional by the time support was formally discontinued.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

>> - What's stopping users from installing Sun C 5.9?
>
> Patches are only provided for installed software to be _updated_.  Sun
> Sun C 5.9 is not an update to 5.8 but a completely new compiler, with a
> suitably new package name, separate support and update arrangements, and
> the like.
[...]
> Sun C 5.9 is incompatible with 5.8, and users may choose to run either
> compiler (as well as later releases) on Solaris 10 systems, until 2027.

Thanks.  The question was if they can install and use Sun C 5.9, and the
answer seems to be "yes".

>> - Finally, why can't we ask these users to run GCC?  We also don't
>>   support MSVC, for example, so adding another unportable compiler to
>>   the list doesn't sound like a disaster (especially since they can just
>>   upgrade to the next version).
>
> AFAIU MSVC is not an ISO C99 compiler, so it's natural that we don't
> support it.  The MSVC build also required its own build system and
> Makefiles (see nt/configure.bat, cf. config.bat), which were already
> nonfunctional by the time support was formally discontinued.

You didn't answer the question, but I did some research myself, and it
seems like you can indeed build GCC 4.9 on Solaris 10.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Thanks.  The question was if they can install and use Sun C 5.9, and the
> answer seems to be "yes".
>
>>> - Finally, why can't we ask these users to run GCC?  We also don't
>>>   support MSVC, for example, so adding another unportable compiler to
>>>   the list doesn't sound like a disaster (especially since they can just
>>>   upgrade to the next version).
>>
>> AFAIU MSVC is not an ISO C99 compiler, so it's natural that we don't
>> support it.  The MSVC build also required its own build system and
>> Makefiles (see nt/configure.bat, cf. config.bat), which were already
>> nonfunctional by the time support was formally discontinued.
>
> You didn't answer the question, but I did some research myself, and it
> seems like you can indeed build GCC 4.9 on Solaris 10.

It is indeed possible, but so is running GCC 3.4.x.  The relevant
question is not the feasibility of upgrading to new compilers, but
whether anyone is interested in building Emacs with such compilers now
or will be in the future, whether on a whim, out of convenience, or
whatnot.

I'm sorry it's come to this, but if __typeof__ is to be used
unconditionally, I will simply leave, because I will not continue being
drained by this exercise where I am prevented from compiling Emacs by my
own preferences in the name of a few score lines of cosmetic code that
neither address bugs nor provide some other significant advantage.  I
only note that many weeks' worth of emails have been exchanged with no
swap macro existing in lisp.h, and that has produced no great disaster.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Sun, 28 Jan 2024 09:51:04 +0800
> 
> AFAIU MSVC is not an ISO C99 compiler

AFAIK, recent versions are.  But we will not support MSVC unless an
active developer comes on board to take up that responsibility,
including the configure phase.

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

[Gregory Heytings]

>
> The errors in lisp.h are caused by your building Emacs with 4-byte 
> longs, hence "CPU".
>

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?

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.

>
> cc: Sun C 5.8 2005/10/13
>
> that is 4 years out of date.  Install:
>
> cc: Sun C 5.8 Patch 121015-07 2009/04/22
>

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.

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.

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

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.

>
> 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.  For example,
>
> https://lists.gnu.org/archive/html/bug-gnulib/2023-10/msg00021.html
>

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

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.

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?

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

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

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

Your build failure is one which we have _fixed_, and holds absolutely no
bearing on our expectations of C compilers.

> All that is irrelevant in the matter at hand.

You don't decide what is relevant or irrelevant.

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

In e32a579975's lisp.h:

#ifndef alignas
# define alignas(alignment) /* empty */
# if USE_LSB_TAG

This definition was lost unintentionally to a succession of changes, and
promptly restored when its absence was brought to our attention.

I'm sorry to be blunt, but if in decision-making you consider and cite
only historical factors to your liking, or in argument you cannot make
the distinction between errors arising from some fundamental limitation
of a compiler and those caused by operator error, to wit, the failure to
provide several required compiler flags and install patches firmly
recommended by the supplier, whether a compiler can and should compile
Emacs is not for you to decide.  So believe what you want--you don't use
Solaris, or TCC, so the subject of your assertions cannot affect you to
any extent.

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

[Eli Zaretskii]

> Date: Sun, 28 Jan 2024 02:22:56 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> Of course, why would you do so, with a guiding principle that
> everyone is wrong?

This is again a kind of remark that I respectfully request you to
avoid.  It adds nothing to your arguments, it just makes it harder for
your opponents to stay technical in their responses.

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

[Gregory Heytings]

>> Of course, why would you do so, with a guiding principle that everyone 
>> is wrong?
>
> This is again a kind of remark that I respectfully request you to avoid. 
> It adds nothing to your arguments, it just makes it harder for your 
> opponents to stay technical in their responses.
>

The problem is the word "stay".  The objections raised in this thread 
have, from the onset, never been technical, although they may have looked 
like technical ones.  The first technical question you asked was "Did 
Stefan's change break some build?  If so, which build became broken and 
why?", to which you got the following reply:

All builds using C compilers that don't support typeof, which is an 
extension provided by GCC.  In my case, the compiler was Sun C 5.12, where 
__typeof__ is available but typeof is not (by default).

That very much looks like a technical objection.  But it's in fact a 
fabricated one.  Because one of the things "configure" already does (since 
2019!) is to check which syntax of typeof should be used.  If "typeof" is 
not supported and "__typeof__" is, a "#define typeof __typeof__" line is 
added in config.h, and "typeof" is replaced transparently by "__typeof__" 
everywhere, by cpp.  Which means that someone building Emacs with a 
compiler in which __typeof__ is available but typeof is not will not see 
anything when typeof is used: no breakage, no error, no warning, nothing.

The other technical objections were of the same level, and were debunked 
one after the other.  You, Stefan and me wasted several hours doing that 
in this absurdly long thread.  As you may know, Alberto Brandolini said 
something interesting about this.

Under such circumstances, a technical and constructive discussion is 
simply impossible.

What remains now is something that looks like a threat: "if __typeof__ is 
to be used unconditionally, I will simply leave".  I don't see the point 
of such a remark, as anyone is free to come and leave at any time, and for 
any reason.  But it does speak about a certain attitude.

With all due respect, IMO, it's that attitude that should be reprimanded, 
not the possibly imperfect words I used to speak out against it.

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

[Eli Zaretskii]

> Date: Tue, 30 Jan 2024 01:59:26 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> >> Of course, why would you do so, with a guiding principle that everyone 
> >> is wrong?
> >
> > This is again a kind of remark that I respectfully request you to avoid. 
> > It adds nothing to your arguments, it just makes it harder for your 
> > opponents to stay technical in their responses.
> 
> The problem is the word "stay".  The objections raised in this thread 
> have, from the onset, never been technical, although they may have looked 
> like technical ones.

What your opponents do is another matter.  We can (and do) ask
everyone to stay technical, but we can only control what we do
ourselves.  However, if you abandon staying technical, you lose the
privilege of demanding that others stay technical.

> The first technical question you asked was "Did 
> Stefan's change break some build?  If so, which build became broken and 
> why?", to which you got the following reply:

You don't need to remind me this discussion: I have, and still am, a
part of it.

> That very much looks like a technical objection.  But it's in fact a 
> fabricated one.

If you think that, post the facts that show those objections are
invalid, but do it in technical terms.  People who read what you write
can make up their own minds regarding the level of "fabrication";
leave it to them, and you will have avoided the need to reprimand you
for the hostile style.

> The other technical objections were of the same level, and were debunked 
> one after the other.

Debunking them on technical terms is all that's needed.  Please leave
the judgment to others, and keep yours to yourself.  Expressing that
judgment explicitly never helps.

> You, Stefan and me wasted several hours doing that in this absurdly
> long thread.

Please leave the worry about our wasted time to us.  We are grown-ups,
and can take care of this just fine, thank you.  Unless you haven't
noticed, I made my conclusions from this argument long ago, and I'm
sure Stefan did as well.  From my POV a 'swap' macro is a go, provided
that it uses 'typeof' where itr is supported, and falls back to
__typeof__ otherwise.

> Under such circumstances, a technical and constructive discussion is 
> simply impossible.

Then my next recommendation is to stop arguing once you lost all hope
to stay technical.

> What remains now is something that looks like a threat: "if __typeof__ is 
> to be used unconditionally, I will simply leave".

Again, please leave these aspects to Stefan and myself: that's part of
our job here.

> With all due respect, IMO, it's that attitude that should be reprimanded, 
> not the possibly imperfect words I used to speak out against it.

I do, and will continue to do, both.

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

[Eli Zaretskii]

> Date: Thu, 18 Jan 2024 01:01:14 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> 
> > Thanks.  Given this information, I don't see why we should be bothered 
> > with the deficiencies of Sun C 5.8.
> 
> FYI, the claim "Sun C 5.8, a C99 compiler that does presently produce 
> working Emacs builds" is pure fantasy, aka fabricated evidence.  I had 
> some free time today, I digged in my archives, and found a copy of Solaris 
> 10 and Sun Studio 11, which I installed in a VM.  The last Emacs version 
> for which Sun C 5.8 produces a working Emacs build is... Emacs 24.
> 
> Much ado about nothing.  Somehow, I'm not surprised.

Thanks for the information, but please avoid such sarcastic remarks
which border on ad-hominem, let alone accusations of "fabrication".
We should be able to have a discussion about technical issues without
resorting to personal attacks.

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

[Gregory Heytings]

>> FYI, the claim "Sun C 5.8, a C99 compiler that does presently produce 
>> working Emacs builds" is pure fantasy, aka fabricated evidence.  I had 
>> some free time today, I digged in my archives, and found a copy of 
>> Solaris 10 and Sun Studio 11, which I installed in a VM.  The last 
>> Emacs version for which Sun C 5.8 produces a working Emacs build is... 
>> Emacs 24.
>>
>> Much ado about nothing.  Somehow, I'm not surprised.
>
> Thanks for the information, but please avoid such sarcastic remarks 
> which border on ad-hominem, let alone accusations of "fabrication". We 
> should be able to have a discussion about technical issues without 
> resorting to personal attacks.
>

There are no accusations or personal attacks in what I said.  I'm merely 
naming upleasant facts.  Loudly and repeatedly making, to support one's 
viewpoint, a technical claim that proves to be just plain false, and doing 
that about a system configuration that is obscure enough that, in all 
likelihood, nobody on this list would have access to it, is precisely 
that: fabricating evidence out of thin air.

However, there was indeed a (light) dose of sarcasm in what I said.  We 
had been told, a few hours before my post, that either the C standards 
committee was wrong and overlooked significant information, or I was wrong 
and took their words out of their context [1].  Admire the "either / or": 
someone else must be wrong, there are no other conceivable possibilities. 
And note that we still haven't seen any of the alluded "significant 
information".  A (light) dose of sarcasm seems appropriate to deal with 
such an arrogant attitude.

[1] https://lists.gnu.org/archive/html/emacs-devel/2024-01/msg00617.html

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

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> There are no accusations or personal attacks in what I said.  I'm
> merely naming upleasant facts.  Loudly and repeatedly making, to
> support one's viewpoint, a technical claim that proves to be just
> plain false, and doing that about a system configuration that is
> obscure enough that, in all likelihood, nobody on this list would have
> access to it, is precisely that: fabricating evidence out of thin air.

Or perhaps it is a system that you, personally, have no access to, and
are not qualified to operate.  I can hardly be held at fault on
"evidence" that a compiler does not function, when such evidence is
generated by incorrectly operating the compiler in question.

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.  For example,

  https://lists.gnu.org/archive/html/bug-gnulib/2023-10/msg00021.html

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

[Eli Zaretskii]

> Date: Sat, 27 Jan 2024 01:25:49 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> 
> >> FYI, the claim "Sun C 5.8, a C99 compiler that does presently produce 
> >> working Emacs builds" is pure fantasy, aka fabricated evidence.  I had 
> >> some free time today, I digged in my archives, and found a copy of 
> >> Solaris 10 and Sun Studio 11, which I installed in a VM.  The last 
> >> Emacs version for which Sun C 5.8 produces a working Emacs build is... 
> >> Emacs 24.
> >>
> >> Much ado about nothing.  Somehow, I'm not surprised.
> >
> > Thanks for the information, but please avoid such sarcastic remarks 
> > which border on ad-hominem, let alone accusations of "fabrication". We 
> > should be able to have a discussion about technical issues without 
> > resorting to personal attacks.
> 
> There are no accusations or personal attacks in what I said.

You are not objective about this, because it's your post.  Please take
it from a bystander who is less emotionally involved in that
discussion: there's a clear personal attack in the wording you've
chosen.

> Loudly and repeatedly making, to support one's viewpoint, a
> technical claim that proves to be just plain false, and doing that
> about a system configuration that is obscure enough that, in all
> likelihood, nobody on this list would have access to it, is
> precisely that: fabricating evidence out of thin air.

Given your command of the English language, I'm sure you could find
any number of ways of expressing the same ideas in a less insulting
manner.  Which is what I'm asking you to do in the future, please,
simply because keeping the flames down makes the discussions more
productive, if not for reasons of general kindness and politeness.

TIA

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

[Richard Stallman]

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

  > __typeof__ is not Standard C, and our declared objective is to be
  > "portable to C99 or later".

The GNU Project's attitude toward standards is that they represent
what other systems are likely to do, and what users are likely to
want.  So we don't ignore them.  But neither do we "obay" them or
"comply" with them.

Regarding __typeof__ and Sun C 5.8, I see three choices:

1. Generally avoid using __typeof__.

2. Not support compilation with that compiler.
That approach is painless _for us_ if GCC does the job
on those systems.

3. Use __typeof__ and add a kludge as a workaround when using that
compiler.

As a general matter, my preference is 3 (if it is not much extra
work), next 2, and least of all 1.  But I don't know the details of
the situation, so I'd rather that the decision be made by people who
do.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> FYI, Stefan's change did not break any build.  "typeof" is supported
>> by all compilers with which Emacs can be built, either with the
>> keyword "typeof" or with the keyword "__typeof__".  The only notable
>> compiler that does not support "typeof" is MSVC, with which Emacs
>> cannot be built.
>
> Stefan's change (which I reverted) did not use __typeof__.

BTW, we already use typeof in Emacs 29.1:

./src/pgtkselect.c:1158:      ldata = (typeof (ldata)) data;

This was introduced in

    commit be35c92c90d455739a6ff9d4beefa2b35d044852
    Author: Po Lu <luangruo@yahoo.com>
    Date:   Tue Jun 21 22:03:42 2022 +0800

        Rewrite PGTK selection code from scratch

I don't see any problem with that, and judging by the lack of bug
reports, neither do our users.  Maybe it's worth changing it to use
__typeof__.

>> "Every implementation in existence since C89 has an implementation of
>> typeof. Some compilers (GCC, Clang, EDG, tcc, and many, many more)
>> expose this with the implementation extension typeof. [...] This
>> feature is the most "existing practice"-iest feature to be proposed to
>> the C Standard, possibly in the entire history of the C standard. The
>> feature was also mentioned in an "extension round up" paper that went
>> over the state of C Extensions in 2007. typeof was also considered an
>> important extension during the discussion of that paper, but nobody
>> brought forth the paper previously to make it a reality."
>
> Considering that EDG and GNU/Linux compilers are the only compilers you
> have named as examples, this list is nowhere near sufficient to prove
> that "typeof" does not break any build.

It was the C standards committee guys that wrote the above, not Gregory.

> Which is a very presumptuous statement whatever the length of your
> list, when a build breaking was in fact the reason for this change...

I guess that wasn't a puregtk build.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> BTW, we already use typeof in Emacs 29.1:
>
> ./src/pgtkselect.c:1158:      ldata = (typeof (ldata)) data;
>
> This was introduced in
>
>     commit be35c92c90d455739a6ff9d4beefa2b35d044852
>     Author: Po Lu <luangruo@yahoo.com>
>     Date:   Tue Jun 21 22:03:42 2022 +0800
>
>         Rewrite PGTK selection code from scratch
>
> I don't see any problem with that, and judging by the lack of bug
> reports, neither do our users.  Maybe it's worth changing it to use
> __typeof__.

I wrote this code aware of the systems on which it would run, and the
systems typeof would affect did not number among them.  As regards
__typeof__, I recall a comment in a GLib header to the effect that it
was unusable under compilers older than GCC 4.8, so we should also avoid
it in the PGTK port.

> It was the C standards committee guys that wrote the above, not
> Gregory.

The C standards committee is not infailable, and this instance is either
one where they have overlooked significant information, or where their
conclusions are being taken out of context and invoked to prove a point
far removed from the context they were drawn in.

> I guess that wasn't a puregtk build.

The PGTK build is designed for systems which run Wayland and GTK 3,
namely GNU/Linux; you'll find that the same code is not present in
xselect.c.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> As regards __typeof__, I recall a comment in a GLib header to the
> effect that it was unusable under compilers older than GCC 4.8, so we
> should also avoid it in the PGTK port.

Which GLib header was that?

GCC 2.95 released in March 2001 is the oldest one I bothered checking,
and its documentation refers to __typeof__.

https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC6
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> As regards __typeof__, I recall a comment in a GLib header to the
>> effect that it was unusable under compilers older than GCC 4.8, so we
>> should also avoid it in the PGTK port.
>
> Which GLib header was that?

/usr/include/glib-2.0/glib/glib-typeof.h.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> As regards __typeof__, I recall a comment in a GLib header to the
>>> effect that it was unusable under compilers older than GCC 4.8, so we
>>> should also avoid it in the PGTK port.
>>
>> Which GLib header was that?
>
> /usr/include/glib-2.0/glib/glib-typeof.h.

AFAICT, that's related to a warning on PowerPC with GCC 4.7.

Emacs doesn't support PowerPC as per etc/MACHINES, so the comment in
that header file does not seem to be relevant to us.

https://bugzilla.gnome.org/show_bug.cgi?id=795138

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> AFAICT, that's related to a warning on PowerPC with GCC 4.7.
>
> Emacs doesn't support PowerPC as per etc/MACHINES, so the comment in

Emacs doesn't support PowerPC on Mac OS X.  The only hardware to have
received RYF certification from the FSF with performance competitive
with PC compatibles released in recent years runs GNU/Linux on powerpc,
so that architecture is far more relevant to us than SPARC or the s390
or the like, all of which we support.  See:

  https://ryf.fsf.org/news/raptor-talos-announcement

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> AFAICT, that's related to a warning on PowerPC with GCC 4.7.
>>
>> Emacs doesn't support PowerPC as per etc/MACHINES, so the comment in
>
> Emacs doesn't support PowerPC on Mac OS X.  The only hardware to have
> received RYF certification from the FSF with performance competitive
> with PC compatibles released in recent years runs GNU/Linux on powerpc,
> so that architecture is far more relevant to us than SPARC or the s390
> or the like, all of which we support.  See:
>
>   https://ryf.fsf.org/news/raptor-talos-announcement

Is there any reason why it's not enough to ask PowerPC users to run GCC
4.8 (released in 2013) if they don't want to see that warning?

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

[Richard Stallman]

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

  > Is there any reason why it's not enough to ask PowerPC users to run GCC
  > 4.8 (released in 2013) if they don't want to see that warning?

Could someone please tell me what the obstacle is to making newer GCC versions
work on that machine?

Has anyone spoken with the GCC developers about fixing it?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Could someone please tell me what the obstacle is to making newer GCC
> versions work on that machine?
>
> Has anyone spoken with the GCC developers about fixing it?

There is no obstacle; as I said, I simply don't want to force users to
upgrade, unless absolutely necessary.  It is irritating to the users and
uncivil on our part.

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

[Dmitry Gutov]

On 22/01/2024 06:48, Po Lu wrote:
> Richard Stallman<rms@gnu.org>  writes:
> 
>> Could someone please tell me what the obstacle is to making newer GCC
>> versions work on that machine?
>>
>> Has anyone spoken with the GCC developers about fixing it?
> There is no obstacle; as I said, I simply don't want to force users to
> upgrade, unless absolutely necessary.  It is irritating to the users and
> uncivil on our part.

Do they upgrade to newer versions of Emacs?

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

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Do they upgrade to newer versions of Emacs?

If they want to, yes.  We aren't forcing their hand.

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

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 22/01/2024 06:48, Po Lu wrote:
>> Richard Stallman<rms@gnu.org>  writes:
>>
>>> Could someone please tell me what the obstacle is to making newer GCC
>>> versions work on that machine?
>>>
>>> Has anyone spoken with the GCC developers about fixing it?
>> There is no obstacle; as I said, I simply don't want to force users to
>> upgrade, unless absolutely necessary.  It is irritating to the users and
>> uncivil on our part.
>
> Do they upgrade to newer versions of Emacs?

More importantly, I'm still waiting for someone to tell us why these
warnings are particularly important.  That GLib silenced them in 2018,
six years ago, does not really cut it.

We don't usually go out of our way to silence all warnings on all old
compilers, do we?

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> More importantly, I'm still waiting for someone to tell us why these
> warnings are particularly important.  That GLib silenced them in 2018,
> six years ago, does not really cut it.
>
> We don't usually go out of our way to silence all warnings on all old
> compilers, do we?

Because I don't want to depart from GLib's practice in the PGTK port
without reason.  We've always maintained that compiling Emacs with
"-ansi" on GNU systems is not a suitable grounds to change our code, and
this instance is no different.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  Richard Stallman <rms@gnu.org>,
>  emacs-devel@gnu.org
> Date: Fri, 26 Jan 2024 10:02:38 +0800
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > More importantly, I'm still waiting for someone to tell us why these
> > warnings are particularly important.  That GLib silenced them in 2018,
> > six years ago, does not really cut it.
> >
> > We don't usually go out of our way to silence all warnings on all old
> > compilers, do we?
> 
> Because I don't want to depart from GLib's practice in the PGTK port
> without reason.  We've always maintained that compiling Emacs with
> "-ansi" on GNU systems is not a suitable grounds to change our code, and
> this instance is no different.

All true, but please don't forget that the issue rears its head only
with very old compilers.  So the problem, such as it exists, is minor
at best, certainly taking into account the amount of energy we wasted
discussing it.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 25 Jan 2024 15:38:32 -0800
> Cc: emacs-devel@gnu.org
> 
> We don't usually go out of our way to silence all warnings on all old
> compilers, do we?

Definitely not, and I presented a few examples of this up-thread.

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

[Richard Stallman]

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

  > >> As regards __typeof__,

I added __typeof__ when I personally was still working on GCC,
which was before version 2.

                              I recall a comment in a GLib header to the
  > >> effect that it was unusable under compilers older than GCC 4.8, so we
  > >> should also avoid it in the PGTK port.

Why can't the PGTK port build with recent GCC?  I suspect this has
nothing to do with __typeof__, but whatever its cause this problem is
important.  It should be fixed -- somewhere.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Why can't the PGTK port build with recent GCC?  I suspect this has
> nothing to do with __typeof__, but whatever its cause this problem is
> important.  It should be fixed -- somewhere.

The PGTK port works as-is, and the selection of systems where it runs is
narrow enough that it is only a regrettable episode of miscommunication
that it has been brought up in this thread, whose subject is code built
_everywhere_.

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

[Gregory Heytings]

>>> As regards __typeof__, I recall a comment in a GLib header to the 
>>> effect that it was unusable under compilers older than GCC 4.8, so we 
>>> should also avoid it in the PGTK port.
>>
>> Which GLib header was that?
>
> /usr/include/glib-2.0/glib/glib-typeof.h.
>

That information is completely irrelevant in the matter at hand.  If, 
instead of throwing it in this discussion, and expecting someone else to 
debunk it, you had taken the time to check what the words "We can only use 
__typeof__ on GCC >= 4.8" in that header mean, you would have seen that:

- this is about GCC < 4.8 (ten year old compilers)

- on a specific platform (PowerPC, which is rarely used nowadays)

- on which GCC displays a bogus "value computed is not used" warning (a 
warning, not an error!)

- when __typeof__ is used in a cast operation on the return type of a 
function.

That's a far cry, to say the least, from "__typeof__ is unusable under 
compilers older than GCC 4.8".

Much ado about nothing, again.

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

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

> - this is about GCC < 4.8 (ten year old compilers)
>
> - on a specific platform (PowerPC, which is rarely used nowadays)
>
> - on which GCC displays a bogus "value computed is not used" warning (a
> warning, not an error!)
>
> - when __typeof__ is used in a cast operation on the return type of a
> function.
>
> That's a far cry, to say the least, from "__typeof__ is unusable under
> compilers older than GCC 4.8".

This is my conclusion as well.  I've spent several hours trying to track
down the actual fix in GCC to get more information about the severity of
the warning, but had to give up because the time I had available ran out.

The reason why GLib introduced their change, AFAICT, was that people
wanted to compile some program depending on it with -Werror.

Based on what I found so far, which honestly wasn't much, I think it's
just a bogus warning, and nothing to worry about.  If anyone can provide
more information about this that would point to something more critical,
please do tell.

It also remains to be seen if we will even get that warning in Emacs,
since it might only show up under specific conditions.

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

[Gregory Heytings]

>
> The reason why GLib introduced their change, AFAICT, was that people 
> wanted to compile some program depending on it with -Werror.
>

Correct.

>
> It also remains to be seen if we will even get that warning in Emacs, 
> since it might only show up under specific conditions.
>

We will not, at least not with a swap macro.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Regardless of portability issues, I think the macro should be called
> SWAP, upper-case, to avoid clashes with functions.

Upper case more conventional for a macro, indeed.  I consider these
three as exceptions: min, max, swap.  The former two, we already have.

But I won't insist on using lower case also for `swap`, if you think
it's better not to.

Do you think it's worth changing upper case function names to lower case
also?  I find lower case names makes code more readable.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 13 Jan 2024 02:02:53 -0600
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Regardless of portability issues, I think the macro should be called
> > SWAP, upper-case, to avoid clashes with functions.
> 
> Upper case more conventional for a macro, indeed.  I consider these
> three as exceptions: min, max, swap.  The former two, we already have.

min and max are standard names defined in many system headers.  So
they are exceptions rather than the rule.

> But I won't insist on using lower case also for `swap`, if you think
> it's better not to.
> 
> Do you think it's worth changing upper case function names to lower case
> also?  I find lower case names makes code more readable.

They are upper-case because they were macros once, and we kept the
letter-case for that reason.

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

[Mattias Engdegård]

13 jan. 2024 kl. 10.14 skrev Eli Zaretskii <eliz@gnu.org>:

>>> Regardless of portability issues, I think the macro should be called
>>> SWAP, upper-case, to avoid clashes with functions.

I agree, better use upper case here. It's a convention to alert the programmer and reader that normal evaluation rules don't apply. After all, we don't want anyone thinking that

  SWAP (int, a[i++], a[j++]);

is a good idea. (Maybe we can make it work using preprocessor trickery but I'd rather not at this point.)

For that matter, we could add code to verify statically that the given type agrees with that of both arguments.

And I think that a swap macro is useful: in any body of code the probability of finding the moral equivalent of a botched swap,

  a := b;
  b := a;

approaches 1 as the code size grows.

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

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> branch: master
>> commit 37889523278fe65733938fb11c3701898309961c
>> Author: Stefan Kangas <stefankangas@gmail.com>
>> Commit: Stefan Kangas <stefankangas@gmail.com>
>>
>>     Add new `swap` macro and use it
>>
>>     A `swap` macro prevents programming errors and is more concise.
>>     It is a natural addition to our existing `min` and `max` macros.
>
> It's well known that a generic "swap" macro is impossible to express in
> Standard C for lack of a standard "typeof"-like expression.  To
> compensate for this limitation, the macro must accept an argument
> identifying the type of the field where the temporary value is saved,
> which is more trouble than it's worth and reintroduces the type
> conversion problems such macros are intended to prevent.
>
> Neither typeof nor __typeof__ are portable by our standards, the latter
> being an extension compatible with the Standard enabled when GCC is
> configured to obey the standard to the letter, while the former is a
> keyword enabled in other situations.

Ouch, right.  I was inspired by some other large project, let's leave it
unnamed, but their C chops were big enough that I let my guard down.
Unfortunately for me, they happen to support far fewer compilers than we
do.  Sorry about that, and thanks for being on your toes.

I had a look at what Gnulib has, and came up with the attached patch.
It still lets us avoid the type conversion problems on GCC, clang and
reasonably recent versions of IBM C and sunc.  I'm not sure it's worth
it though, so perhaps my original patch should just be reverted.

I copied in Paul just in case, and I'm hoping Eli will chime in too.

[-- Attachment #2: portable-swap.diff --]
[-- Type: text/x-diff, Size: 9228 bytes --]

diff --git a/lwlib/xlwmenu.c b/lwlib/xlwmenu.c
index a3d9474bed0..d6fa23841a3 100644
--- a/lwlib/xlwmenu.c
+++ b/lwlib/xlwmenu.c
@@ -671,7 +671,7 @@ draw_shadow_rectangle (XlwMenuWidget mw, Window window, int x, int y,
     }
 
   if (!erase_p && down_p)
-    swap (top_gc, bottom_gc);
+    swap (GC, top_gc, bottom_gc);
 
   /* Do draw (or erase) shadows */
   points [0].x = x;
@@ -752,7 +752,7 @@ draw_shadow_rhombus (XlwMenuWidget mw, Window window, int x, int y,
     }
 
   if (!erase_p && down_p)
-    swap (top_gc, bottom_gc);
+    swap (GC, top_gc, bottom_gc);
 
   points [0].x = x;
   points [0].y = y + height / 2;
diff --git a/src/androidterm.c b/src/androidterm.c
index 34734e63c37..851a066316a 100644
--- a/src/androidterm.c
+++ b/src/androidterm.c
@@ -5869,7 +5869,7 @@ android_get_surrounding_text (void *data)
      bad input methods.  */
 
   if (request->end < request->start)
-    swap (request->start, request->end);
+    swap (ptrdiff_t, request->start, request->end);
 
   /* Retrieve the conversion region.  */
 
diff --git a/src/buffer.c b/src/buffer.c
index 14c67224551..c03170e8c2d 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -3591,7 +3591,7 @@ DEFUN ("make-overlay", Fmake_overlay, Smake_overlay, 2, 5, 0,
   CHECK_FIXNUM_COERCE_MARKER (end);
 
   if (XFIXNUM (beg) > XFIXNUM (end))
-    swap (beg, end);
+    swap (Lisp_Object, beg, end);
 
   ptrdiff_t obeg = clip_to_bounds (BUF_BEG (b), XFIXNUM (beg), BUF_Z (b));
   ptrdiff_t oend = clip_to_bounds (obeg, XFIXNUM (end), BUF_Z (b));
@@ -3611,7 +3611,7 @@ DEFUN ("make-overlay", Fmake_overlay, Smake_overlay, 2, 5, 0,
 modify_overlay (struct buffer *buf, ptrdiff_t start, ptrdiff_t end)
 {
   if (start > end)
-    swap (start, end);
+    swap (ptrdiff_t, start, end);
 
   BUF_COMPUTE_UNCHANGED (buf, start, end);
 
@@ -3651,7 +3651,7 @@ DEFUN ("move-overlay", Fmove_overlay, Smove_overlay, 3, 4, 0,
   CHECK_FIXNUM_COERCE_MARKER (end);
 
   if (XFIXNUM (beg) > XFIXNUM (end))
-    swap (beg, end);
+    swap (Lisp_Object, beg, end);
 
   specbind (Qinhibit_quit, Qt); /* FIXME: Why?  */
 
diff --git a/src/dispnew.c b/src/dispnew.c
index 78ec3537a35..a3e6ca416db 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -649,7 +649,7 @@ reverse_rows (struct glyph_matrix *matrix, int start, int end)
   int i, j;
 
   for (i = start, j = end - 1; i < j; ++i, --j)
-    swap (matrix->rows[i], matrix->rows[j]);
+    swap (struct glyph_row, matrix->rows[i], matrix->rows[j]);
 }
 
 
@@ -975,7 +975,7 @@ swap_glyphs_in_rows (struct glyph_row *a, struct glyph_row *b)
 
       while (glyph_a < glyph_a_end)
 	{
-	  swap (*glyph_a, *glyph_b);
+	  swap (struct glyph, *glyph_a, *glyph_b);
 	  ++glyph_a;
 	  ++glyph_b;
 	}
diff --git a/src/editfns.c b/src/editfns.c
index 2e455a2efed..f31d8f5aef3 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -1753,7 +1753,7 @@ DEFUN ("insert-buffer-substring", Finsert_buffer_substring, Sinsert_buffer_subst
   b = !NILP (start) ? fix_position (start) : BUF_BEGV (bp);
   e = !NILP (end) ? fix_position (end) : BUF_ZV (bp);
   if (b > e)
-    swap (b, e);
+    swap (EMACS_INT, b, e);
 
   if (!(BUF_BEGV (bp) <= b && e <= BUF_ZV (bp)))
     args_out_of_range (start, end);
@@ -1808,7 +1808,7 @@ DEFUN ("compare-buffer-substrings", Fcompare_buffer_substrings, Scompare_buffer_
   begp1 = !NILP (start1) ? fix_position (start1) : BUF_BEGV (bp1);
   endp1 = !NILP (end1) ? fix_position (end1) : BUF_ZV (bp1);
   if (begp1 > endp1)
-    swap (begp1, endp1);
+    swap (EMACS_INT, begp1, endp1);
 
   if (!(BUF_BEGV (bp1) <= begp1
 	&& begp1 <= endp1
@@ -1833,7 +1833,7 @@ DEFUN ("compare-buffer-substrings", Fcompare_buffer_substrings, Scompare_buffer_
   begp2 = !NILP (start2) ? fix_position (start2) : BUF_BEGV (bp2);
   endp2 = !NILP (end2) ? fix_position (end2) : BUF_ZV (bp2);
   if (begp2 > endp2)
-    swap (begp2, endp2);
+    swap (EMACS_INT, begp2, endp2);
 
   if (!(BUF_BEGV (bp2) <= begp2
 	&& begp2 <= endp2
diff --git a/src/eval.c b/src/eval.c
index 6a866d6cc32..7d89c0b621e 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -2794,9 +2794,9 @@ DEFUN ("run-hook-with-args-until-failure", Frun_hook_with_args_until_failure,
 static Lisp_Object
 run_hook_wrapped_funcall (ptrdiff_t nargs, Lisp_Object *args)
 {
-  swap (args[0], args[1]);
+  swap (Lisp_Object, args[0], args[1]);
   Lisp_Object ret = Ffuncall (nargs, args);
-  swap (args[1], args[0]);
+  swap (Lisp_Object, args[1], args[0]);
   return ret;
 }
 
diff --git a/src/fns.c b/src/fns.c
index c8adc5cb891..9e7f43b58e1 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -5674,7 +5674,7 @@ extract_data_from_object (Lisp_Object spec,
       b = !NILP (start) ? fix_position (start) : BEGV;
       e = !NILP (end) ? fix_position (end) : ZV;
       if (b > e)
-	swap (b, e);
+	swap (EMACS_INT, b, e);
 
       if (!(BEGV <= b && e <= ZV))
 	args_out_of_range (start, end);
diff --git a/src/lisp.h b/src/lisp.h
index f96932ab0c1..a9782868157 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -68,8 +68,13 @@ #define max(a, b) ((a) > (b) ? (a) : (b))
 #define min(a, b) ((a) < (b) ? (a) : (b))
 
 /* Swap values of a and b.  */
-#define swap(a, b) \
-  do { typeof (a) __tmp; __tmp = (a); (a) = (b); (b) = __tmp; } while (0);
+#if _GL_HAVE___TYPEOF__
+#define swap(type, a, b)							\
+  do { __typeof__ (a) __tmp; __tmp = (a); (a) = (b); (b) = __tmp; } while (0);
+#else
+#define swap(type, a, b)							\
+  do { type __tmp; __tmp = (a); (a) = (b); (b) = __tmp; } while (0);
+#endif
 
 /* Number of elements in an array.  */
 #define ARRAYELTS(arr) (sizeof (arr) / sizeof (arr)[0])
diff --git a/src/regex-emacs.c b/src/regex-emacs.c
index fdc2cc63445..afaf0d06bd1 100644
--- a/src/regex-emacs.c
+++ b/src/regex-emacs.c
@@ -2930,7 +2930,7 @@ forall_firstchar_1 (re_char *p, re_char *pend,
 	    /* We have to check that both destinations are safe.
 	       Arrange for `newp1` to be the smaller of the two.  */
 	    if (newp1 > newp2)
-	      swap (newp1, newp2);
+	      swap (re_char *, newp1, newp2);
 
 	    if (newp2 <= p_orig) /* Both destinations go backward!  */
 	      {
diff --git a/src/textconv.c b/src/textconv.c
index e0707522d7e..c8599f78a54 100644
--- a/src/textconv.c
+++ b/src/textconv.c
@@ -383,8 +383,8 @@ textconv_query (struct frame *f, struct textconv_callback_struct *query,
   if (end < pos)
     {
       eassert (end_byte < pos_byte);
-      swap (pos_byte, end_byte);
-      swap (pos, end);
+      swap (ptrdiff_t, pos_byte, end_byte);
+      swap (ptrdiff_t, pos, end);
     }
 
   /* Return the string first.  */
@@ -1903,7 +1903,7 @@ get_extracted_text (struct frame *f, ptrdiff_t n,
 
 	  /* Sort start and end.  */
 	  if (start > end)
-	    swap (start, end);
+	    swap (ptrdiff_t, start, end);
 	}
       else
 	goto finish;
@@ -2002,7 +2002,7 @@ get_surrounding_text (struct frame *f, ptrdiff_t left,
   /* Now sort start and end.  */
 
   if (end < start)
-    swap (start, end)
+    swap (ptrdiff_t, start, end)
 
   /* And subtract left and right.  */
 
diff --git a/src/textprop.c b/src/textprop.c
index ec9435219ea..118a5831c10 100644
--- a/src/textprop.c
+++ b/src/textprop.c
@@ -142,7 +142,7 @@ validate_interval_range (Lisp_Object object, Lisp_Object *begin,
     return NULL;
 
   if (XFIXNUM (*begin) > XFIXNUM (*end))
-    swap (*begin, *end);
+    swap (Lisp_Object, *begin, *end);
 
   if (BUFFERP (object))
     {
@@ -2196,7 +2196,7 @@ verify_interval_modification (struct buffer *buf,
     return;
 
   if (start > end)
-    swap (start, end);
+    swap (ptrdiff_t, start, end);
 
   /* For an insert operation, check the two chars around the position.  */
   if (start == end)
diff --git a/src/w32uniscribe.c b/src/w32uniscribe.c
index c417159cf9e..798a90bf594 100644
--- a/src/w32uniscribe.c
+++ b/src/w32uniscribe.c
@@ -768,7 +768,7 @@ #define OTF_INT16_VAL(TABLE, OFFSET, PTR)		     \
     BYTE data[2];					     \
     if (GetFontData (context, TABLE, OFFSET, data, 2) != 2)  \
       goto font_table_error;				     \
-    swap (data[0], data[1]);				     \
+    swap (BYTE, data[0], data[1]);			     \
     memcpy (PTR, data, 2);				     \
   } while (0)
 
diff --git a/src/xfaces.c b/src/xfaces.c
index f79eb022e15..95ae3b4b1bc 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -1357,7 +1357,7 @@ load_face_colors (struct frame *f, struct face *face,
 
   /* Swap colors if face is inverse-video.  */
   if (EQ (attrs[LFACE_INVERSE_INDEX], Qt))
-    swap (fg, bg);
+    swap (Lisp_Object, fg, bg);
 
   /* Check for support for foreground, not for background because
      face_color_supported_p is smart enough to know that grays are
diff --git a/src/xterm.c b/src/xterm.c
index 0b83b0554b3..92e51577cec 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -1571,8 +1571,8 @@ #define SWAPCARD32(l)				\
     struct { unsigned t : 32; } bit32;		\
     char *tp = (char *) &bit32;			\
     bit32.t = l;				\
-    swap (tp[0], tp[3]);			\
-    swap (tp[1], tp[2]);			\
+    swap (char, tp[0], tp[3]);			\
+    swap (char, tp[1], tp[2]);			\
     l = bit32.t;				\
   }
 
@@ -1581,7 +1581,7 @@ #define SWAPCARD16(s)				\
     struct { unsigned t : 16; } bit16;		\
     char *tp = (char *) &bit16;			\
     bit16.t = s;				\
-    swap (tp[0], tp[1]);			\
+    swap (char, tp[0], tp[1]);			\
     s = bit16.t;				\
   }
 

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Ouch, right.  I was inspired by some other large project, let's leave it
> unnamed, but their C chops were big enough that I let my guard down.
> Unfortunately for me, they happen to support far fewer compilers than we
> do.  Sorry about that, and thanks for being on your toes.
>
> I had a look at what Gnulib has, and came up with the attached patch.
> It still lets us avoid the type conversion problems on GCC, clang and
> reasonably recent versions of IBM C and sunc.  I'm not sure it's worth
> it though, so perhaps my original patch should just be reverted.

That's worse, since code using the macro incorrectly will function on
some compilers but not others.  I suggest leaving programmers to
manually swap variables as they have always done: the brief fascination
with macros all C programmers experience never fails to produce
unnecessary macros for simple operations that yield little benefit, and
"swap" operations are no exception.

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

[Andreas Schwab]

On Jan 06 2024, Stefan Kangas wrote:

> diff --git a/src/lisp.h b/src/lisp.h
> index f96932ab0c1..a9782868157 100644
> --- a/src/lisp.h
> +++ b/src/lisp.h
> @@ -68,8 +68,13 @@ #define max(a, b) ((a) > (b) ? (a) : (b))
>  #define min(a, b) ((a) < (b) ? (a) : (b))
>  
>  /* Swap values of a and b.  */
> -#define swap(a, b) \
> -  do { typeof (a) __tmp; __tmp = (a); (a) = (b); (b) = __tmp; } while (0);
> +#if _GL_HAVE___TYPEOF__
> +#define swap(type, a, b)							\
> +  do { __typeof__ (a) __tmp; __tmp = (a); (a) = (b); (b) = __tmp; } while (0);
> +#else
> +#define swap(type, a, b)							\
> +  do { type __tmp; __tmp = (a); (a) = (b); (b) = __tmp; } while (0);
> +#endif

Neither of these definitions are future proof: __tmp as a reserved
identifier might clash with future implementations.  Moreover, the first
argument can easily become out of date without notice.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."