From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: master 37889523278: Add new `swap` macro and use it Date: Sun, 28 Jan 2024 12:03:24 +0800 Message-ID: <87sf2ihzoz.fsf@yahoo.com> References: <170452579053.27998.16123231327386305897@vcs2.savannah.gnu.org> <87plye9ahs.fsf@yahoo.com> <83o7dyua0d.fsf@gnu.org> <87le9297ei.fsf@yahoo.com> <87cyue92fx.fsf@yahoo.com> <877ckm8uzz.fsf@yahoo.com> <83v886sgtl.fsf@gnu.org> <4719da9bc2bbcffdb634@heytings.org> <87bk9o1ooo.fsf@yahoo.com> <83cyu4fl4o.fsf@gnu.org> <877ckc1gs9.fsf@yahoo.com> <83a5p8fehd.fsf@gnu.org> <83bk9mepkt.fsf@gnu.org> <9245debeed69c26665f0@heytings.org> <87h6jbwfu4.fsf@yahoo.com> <2f5a5ec4d5c204a5200d@heytings.org> <87il3flbxj.fsf@yahoo.com> <37364cd16c3e66d03224@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28110"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , stefankangas@gmail.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 28 05:04:36 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rTwPL-000767-Lg for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 05:04:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTwOW-0004YJ-DQ; Sat, 27 Jan 2024 23:03:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTwOS-0004Xl-Eg for emacs-devel@gnu.org; Sat, 27 Jan 2024 23:03:40 -0500 Original-Received: from sonic316-22.consmr.mail.ne1.yahoo.com ([66.163.187.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rTwOP-0006Tb-FY for emacs-devel@gnu.org; Sat, 27 Jan 2024 23:03:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706414614; bh=aNU2ie/XjAJzeTAZrgNfoXB8BA5MlaQYqm3FlaSunZA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=gQqDgmGF6ylkjhSWQvUQgexrPEWkMIYm49OICYhlhCNDOlUQ+z6zQycv+8SJC2RjO/8cjoUwjFqoeDvVZbbbo53NoWUeYNRpLuUDzwjubX7l/OBMZ7RJQDgZKwifDVlimDwOSowAayulOfp22gGJQ+gq5XI0/OWy68SGPWBJN9KXjRnjxL9LIqyCxYVVJ3fCmsKKnUjrlpZnXcdhsul/O9ND4UBdeITHGC4IQiRrnvgpcAmxi2E34o2fna5VW/SyqN7kiRaBvhBG7ToQW/iSx3p5RXxyPHQQevdzjChyuGRPo1GCsVFfPn2xMhhG90Pcf1eUtcgI/cz/1lRd+Stgzw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706414614; bh=wSgwFmwaDf968h1bn/HzhdaUpdsUTq9JOOlv1AwEzPS=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=HxM4i4C97toqHgtTgmf1LdNXcTCSaGNdZWoLzRCuLsEai8ckbhnodzTJsmSSlY9RQDazfzViCbf3P5Ya0+WIVzGLgLumtOtJ6UUSaCM1uR/PhtQAgz3dD35CiBHEFqOdjQeg7xY68EU80UFH1/wvo9c7KzVKvZoM7AgzRX79avscAd6QWhhoV1Pa7mVkRv7B+9EulQ0yeo/FFbCZM8sqVDd24lBHc4H+dwKgQUK8DatK6RvJh1UbBDs3nDWrQHW7EoCju0yVEWhKY2uzEkIIXANrXyn82feGBq5PW5Qia11M1s8DnXumLD2oHDbdiGGYfAhPOemqzVs96zUU0mwGOA== X-YMail-OSG: 9KXqkdAVM1k90gIjQ42A3Oo0PkJW0N0MbOTgR1agmx_8DBfhwTxh2wQsIS.LGrh ZIKrJ7AqazbCh4I0UKIV_7uztaNAABFGgEdgRzshNnDlQTxd9Nw3pQKmsBn_nFB9EXMdc91AA9Xx ZEzNmV8h5ZxzP_sGDq8fcCh4.iqubq1j4hpKB5cR0QajXv.OlP7opOb2IvwhNAPwwUZwxUbD0d.u d7k5ZYyB3JnnYKsaOenvIDoGLGpeIEUcVyiUEnQg_2b8UaOzR1u8iaWKAyksVXb1P5c2NH8W_my6 bpFvTUrUEGhcoFRWmxR2HksKzQpJCCAX3Jz52CKxegUXShEX31lLIevwHB5B4l8SYRfodzTdgTnU 85M3OwUCCuyE3chydEXxQcQJ4rI3Egm3TX9vbLI6UR8Nlb6y9CHwNlAF3gUtO4HXeO7dlgA4Ipfz XqKivw41DqZ8hGSzZSwDnooVuw4BuxMeCGAChwcppcn0EtzXozIpTgT1Tr1YX4OaUrtFrCsAgcnJ lz17j_NlHLweEok2Esi1zvPo2Vf0EfGd3bLYVuDWQCLN_ntm5y1IYL1MxpNgU6sRXi12bSnoezpz dp7IEE917asOZMdo.iBo14LFUP4vVunjLzQnTrDNhO7sHPoDBN.THrfplXDsFFAZVQNs6sQNe0f5 c82aa3sJCKyc.8MVUPlQseD8gTBQFsmEbYLPLoguBJDZ9qd43fNMGyFrNHWGmE7ZSF4JRpHv_aRy H02JyNn7JD4eONiplKV5eDxd52SIPJtHLXiTrKYc4USk0Ldht29lFQEsQkifqJyfSqJhnE8fSwyQ WdLedDKOQtLE3Y_Uocy5eYx68AwucrZYqjPhgwnrDz X-Sonic-MF: X-Sonic-ID: c0a4912f-6778-4edf-93e1-dd1aeafc8604 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 28 Jan 2024 04:03:34 +0000 Original-Received: by hermes--production-sg3-6dc75bc8fb-n9pfz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a96119530cee2142d295729528fa640c; Sun, 28 Jan 2024 04:03:30 +0000 (UTC) In-Reply-To: <37364cd16c3e66d03224@heytings.org> (Gregory Heytings's message of "Sun, 28 Jan 2024 02:22:56 +0000") X-Mailer: WebService/1.1.22046 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.187.148; envelope-from=luangruo@yahoo.com; helo=sonic316-22.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315519 Archived-At: Gregory Heytings 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.