emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Kangas
Subject: Re: master 37889523278: Add new `swap` macro and use it
Date: Wed, 17 Jan 2024 02:16:54 -0800

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.



reply via email to

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