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, 07 Jan 2024 18:36:07 +0800 Message-ID: <87o7dx77mw.fsf@yahoo.com> References: <170452579053.27998.16123231327386305897@vcs2.savannah.gnu.org> <20240106072311.28B8FC0034E@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> <83plyescg9.fsf@gnu.org> <87wmsl7wh9.fsf@yahoo.com> <87sf397faq.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19000"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 07 11:37:18 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 1rMQWs-0004oL-AF for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jan 2024 11:37:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMQW9-00053D-FH; Sun, 07 Jan 2024 05:36:33 -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 1rMQW1-00052A-QX for emacs-devel@gnu.org; Sun, 07 Jan 2024 05:36:28 -0500 Original-Received: from sonic302-21.consmr.mail.ne1.yahoo.com ([66.163.186.147]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rMQVz-0003BI-RK for emacs-devel@gnu.org; Sun, 07 Jan 2024 05:36:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704623781; bh=rUFdgutFTSB8sqncMi1NHKVv0qNP/RZXXMmEzsa68Z4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=JZWs7NeYhw0aKE37SjYdtnC7xptU12RQwZGbaITyXBdJcU41ZmKq6eYQu4MJFMhF+Q4swsmuw87PL73tmK36FAwt0ysxFp5JPkvtTA7Uw4lLMNcEqAuSRvt3Ofx3fIyIBNRuPcvUIHEnCa+4kJSCKB95K2LozHIef1qN9EbBCi54jB9blmNgiSvd99wa5qXQ8hgOZl954Atj5RTvp23G6c9//cc/XFhvKbfpT1oUY8nAizvYf57U9tRmy0WVCZTsA/a0k2nh8tlEGcs3idIygvFjptW6KCr0H83KJRJmqX4BSZPMGPRLJsgVjPOsWJouJnl9xnzv1YVMGfZvj4zEGA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704623781; bh=iNRa1RVBChrCKmWqmDGpHcQr+UrQPDBnJ+Rjiq6/tsi=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=RQJCOt89qYbhLz/RtH4/c8sJPRSxYjFNni1Yod3t8Afk5u1mZwto0fWSxr88pMSYpPvIVRdJk1K2m0HxmG5S6l4U7u5flpgKfx4GmiNQarKIqJxl1cVcB/ZgmxPJLo+MqSb+44SOc6jn0VSm2Qg5rF3h6qhg52420cDtoqr0BhvrHYY9Xj9OG8q8Xn7PGnXZPFkaw67na0xvJaiXQEhUWPTYGjkzZ1lPHO+Nij/ahZO4+aTt0w0MiIvnSGH4N331rhBUqasgPfbTjL3QyO1t8M3zYw3y9VWTzMJtHlTJEFF4GfvZ0gZia4JYA4h00l8g6du+ke/KSioB1DtILRfBBA== X-YMail-OSG: sH62Ge8VM1lqNZF0ys0WjlfZEdh6GZvLMJWmdVyT2PPqyj3A9_ccbiHtMzXaEoK qc.8NbTIVscrIGSKJaM.qwB2qKY8g8Rzyw3ifxv2elhAMM2gKKuvEcvO0kjw.CZJnya633.qu2Ok y3wDBhVK.YlrJzcQg9HgOay4ERUsDiDJQM71bhloCHpi4JZxg7OBUNvIv7yWoSd.Qikc3mEkKSjd 1kNqhAfAVk9dBW9W8BmjaC6jFrXBkhjg_d1H4O9M4cmnuxW4lAcbRwdEhdSN2edb4qp5CSjfkc_D wGgl0rnRHmgLztKIscFoE_.k_fD6bsAn5CdjPNSa9Vf3JBEssE10G43_88nF38rmH2pzr8wJj5uY 4xJTAnCaqniNMevQGChBVcOQUmzVaO.6eNGpKqGUvDw191KC5.9PpbWvjDEWdyQv9UiNl8Jtzfu0 TbKv7e_ooH_X8fZ3GdoqtSFRHL70aa8sEQnmpxBOyhvW3lQ1uHOAvvgGkjNu9Sbz2mIIJidlwjIi iJtJLdwhW1ShuNLN0Ok6Cg2DxtjI_aLxNgmi2VxZqGFqiilVkuTIp.sZO1qVVtcyK9_881gsepjR dtdyKS8cOilmsipzI26VFjr25L1VEqxqUSVaS8WAYir5lqM04.eC2ZGggy5QVE4g58vyWNzLe_wU FERwYwnEpgwduNgxaItX2FrHWWVI1xo3tqIElRzHYMrLKy.xQ6bmmUWO40T5WDMUWRoegiD0SMKj SF3G.LPIStD0PBl0bNXOoGYEwUIya_qY9M.p2cOTIv8ahr2C4PY3RhWrWdO4Gwi9LxAS2tgcdBMH dNhDw5x._o03fN172qer9dAHZlEZzz_9VhTRFKSkSe X-Sonic-MF: X-Sonic-ID: 98e13471-d21e-496c-a692-3896751c9ace Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Jan 2024 10:36:21 +0000 Original-Received: by hermes--production-sg3-65d57d948b-ngz7m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 55dd6c6e4259ff943348b133a502c474; Sun, 07 Jan 2024 10:36:15 +0000 (UTC) In-Reply-To: (Stefan Kangas's message of "Sun, 7 Jan 2024 01:45:54 -0800") X-Mailer: WebService/1.1.21952 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.186.147; envelope-from=luangruo@yahoo.com; helo=sonic302-21.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:314677 Archived-At: Stefan Kangas 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.