bug#65491: [PATCH] Improve performance allocating vectors

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

16 sep. 2023 kl. 18.54 skrev Eli Zaretskii <eliz@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.