bug#65491: [PATCH] Improve performance allocating vectors

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Sat, 16 Sep 2023 19:03:33 +0200
> Cc: 65491@debbugs.gnu.org,
>  monnier@iro.umontreal.ca
> 
> 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. 

Then just casting should do, no?  Why the subtraction?

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

Sorry, this is not a reason good enough to make changes in these
parts.  However "unreliable" the old code worked for many moons, luck
or no luck, so if there's no other reason, I prefer to leave it alone.

And I'd like to hear from Paul before we make any further changes in
that area, please.