From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#65491: [PATCH] Improve performance allocating vectors Date: Sun, 17 Sep 2023 11:02:47 +0800 Message-ID: <871qexzelk.fsf@yahoo.com> References: <6B2EDD07-AAEB-40E8-B369-F634296BD3D9@gmail.com> <83v8cagkqv.fsf@gnu.org> <83ttrugkj2.fsf@gnu.org> <83sf7egitx.fsf@gnu.org> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34146"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 65491@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 17 05:04:13 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qhi4z-0008hk-8K for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Sep 2023 05:04:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhi4j-00015y-39; Sat, 16 Sep 2023 23:03:57 -0400 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 1qhi4h-00015d-OF for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 23:03:55 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qhi4g-0007XA-GD for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 23:03:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qhi4n-0000MW-Q8 for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 23:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Sep 2023 03:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65491 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65491-submit@debbugs.gnu.org id=B65491.16949197931306 (code B ref 65491); Sun, 17 Sep 2023 03:04:01 +0000 Original-Received: (at 65491) by debbugs.gnu.org; 17 Sep 2023 03:03:13 +0000 Original-Received: from localhost ([127.0.0.1]:48791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhi40-0000Kz-GQ for submit@debbugs.gnu.org; Sat, 16 Sep 2023 23:03:12 -0400 Original-Received: from sonic312-25.consmr.mail.ne1.yahoo.com ([66.163.191.206]:43066) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhi3y-0000Kk-8g for 65491@debbugs.gnu.org; Sat, 16 Sep 2023 23:03:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1694919777; bh=DK20AyLUqH3ADCLol0zn3FbcQk4Ud4l9zsEZd5BeqKQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=GISyLNYBAVXa+bAC1jznpBUhHcRqOcILNNDWTQoXuESN2jQsCUR1/aIIkJ71jp3gZE1rSdtyK/sNb9RvaZR5FTIuCCvro3mJbAKlu6zfmga/Q9qb42R5cFZ7MbQ7ELwZWfVkMKAOLnL2Zx9Dbm5mvnSM1Z0LjUHbmETsbibqD2tpic9ZiCZysKKSLOLu7NFFW4W5YGEH8tC4FyGd1dd3K/mU0VKj6EHodVPifdG4uUpkwk+2cC1vjFdAD/ZVrGEERqwcFCIHuNE5YMm2lo6YDfdgDkv1ahUz5cwJGOEBmpdnALi9lyNOaUTMMioAN9iUrquyY5Spb94Wml54k0VPcA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1694919777; bh=/g3iGj2p3T7kdapuhAoQRgmkSdPF9JAIQs+0ehZWmao=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=qP2cWPZWjlXA9jZ7MRI6J2iQSLX+R4r2tBX+tyMqXSIaIgX1D2MD6pYJNnz7mTgi3QwvV6DCOTOxTVKJnb+sCE9CVF70h0ypenrucnZeY964MgysABnt/OanVWd5+TJneSeFMUZhPj8Hbx41BL7wzKYBl5cYW0cKdXGzMOCZTJheH76Yo+HK5hfC4YxzLzKYDaJdpStipBA5WRAUxF6YxCBe27w5fKoRrrwpyrjK65XJbl1n+7PLahi5KNMjp3S5kXGIrYS+RHnlj30NDVAVKJu6CL6UuBFjuMTD2kfqnMdgL/my/ox7Z6+jOILEDKGAsjIUZ/T8eygwoz3kP+hBtQ== X-YMail-OSG: nJIJVecVM1ku4vLc7OrO9jIJ5Mp1ZZ_OVKP8mMMDz0zXsVQThQRUVkyyddA.biQ 3Iyn1aKCKdWtYO.bAs454HC0jzDNiMzfwby4BiWn4MzJzJzqC2x6NsL6CaFFcinbQNJ3FsNWaUkZ 5eknrSy_LLat0ce8bUMozUJB3TT58JLVOiVJ.VflTBnCZnMWTJix9FzEw3oICEBKqHPy1vB1YQI6 .BfRrmcVXLL0Wex00kGOIkw2tJQEBd5lEGALKOXeHYyHjVH86E.TaIQa4Vz7P9Y01u00jUZJS4mf 5qez4rKe7u9E2DG3jwc._VYNdZghsyYL7X9yPN6eGCk3PD2eow.s3Ompig3G0mx9HC7KbNz6PbIc kWgQ16fgBL9R3TpShiGlYrvuPppw3deukW4fw6yZc0pqvB3i2jWIZNsQJNHlQu945ARkhpQ9hlQp rixi5RpvLvpOSc4qd3GUfal6XrqY3WVm6QuAttrBB3oFxrca3BBeGqrGl2c5tzwFlc76sj9YGf.r 7rbfzRHwSg6E8j.n7JKTXElOYNUyNerBfFu6I3V7odDkn2YdTCO_vMxR8RclrrZKyTTfILvG4j.v Ys6fR0hlIBmcn21es47JYEZCcO0Xku1AtD8bO_BaGbinoeoEgyDdNSNaG8vOdaZlKQsMohz7S2TM e1urRkto_qKO4Otlw.SjCijeI9KnMeML84W3Td2SgIF33G6A8Km0lzJrTpdYFGSwBVDe_HbVIWzT 6saJC_5ik6tJSCO23rWCqb4._BNfX559cupsPp6oMfdyQt34.XS6WmLqXN46WtRt72TnFObquxkj NwnRfTEiNkESVNlpWHrN6cglL4THN2ve2ERzLUOtyd X-Sonic-MF: X-Sonic-ID: ff4d7ede-2a63-4ad8-b882-bec0a0c3a137 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Sun, 17 Sep 2023 03:02:57 +0000 Original-Received: by hermes--production-sg3-55c667b499-zxx5q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2b7dec72eaba8ae0d65bfa0cb14b8994; Sun, 17 Sep 2023 03:02:54 +0000 (UTC) In-Reply-To: ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Sat, 16 Sep 2023 19:03:33 +0200") X-Mailer: WebService/1.1.21797 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270659 Archived-At: Mattias Engdeg=C3=A5rd writes: > 16 sep. 2023 kl. 18.54 skrev Eli Zaretskii : > >> It does, but LISP_WORD_TAG(type) is a 64=3Dbit type with the only bits >> set above 32 bit, so how casting it to uintptr_t is TRT? > > Because XUNTAG is used to get the pointer part; we don't want the tag bit= s.=20 > >> Why did you need to change the original cast in the first place? > > The commit message tried to explain that, but in essence, the old code > untagged a Lisp_Object value by casting it to char *, then do pointer > arithmetic on that, and then cast the result to whatever pointer we > want. > > The C standard severely restricts pointer arithmetic: in particular, > for P+X where X is an integer and P is a pointer, P cannot be null > (nor will P+X, since both P and P+X must be pointers to objects in the > same array). > > This means that XUNTAG could never reliably untag a null pointer and > this did cause mayhem in some places. We have just been lucky not to > trigger it so far but I noticed when attempting to make some > innocent-looking changes. Within Standard C, the result of converting a pointer value to an integer and vice versa is also implementation defined behavior. GCC regards converting an integer derived from a pointer value back to a pointer as undefined behavior, should the resulting pointer point to an object outside that which the pointer value that gave rise to the original integer references. From `(gcc)Arrays and Pointers': When casting from pointer to integer and back again, the resulting pointer must reference the same object as the original pointer, otherwise the behavior is undefined. That is, one may not use integer arithmetic to avoid the undefined behavior of pointer arithmetic as proscribed in C99 and C11 6.5.6/8. So whether pointer or integer arithmetic is employed in XUNTAG makes no real difference to us, where undefined behavior is concerned, inasmuch as other compilers only afford us even more latitude. For example, Sun's C compiler documentation actively encourages using pointer arithmetic in lieu of integer arithmetic, and speaks nothing of pointer arithmetic between different objects being forbidden. And all other things being equal, I would rather see existing, time-tested, almost primordial code preserved intact.