GNU bug report logs - #65491
[PATCH] Improve performance allocating vectors

Previous Next

Full log

Message #73 received at 65491 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65491 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#65491: [PATCH] Improve performance allocating vectors
Date: Sat, 16 Sep 2023 19:03:33 +0200

16 sep. 2023 kl. 18.54 skrev Eli Zaretskii <eliz <at> gnu.org>:

> It does, but LISP_WORD_TAG(type) is a 64=bit 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 bits. 

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.