GNU bug report logs -
#65491
[PATCH] Improve performance allocating vectors
Previous Next
Full log
Message #79 received at 65491 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Sat, 16 Sep 2023 19:03:33 +0200
> Cc: 65491 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
>
> 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.
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.
This bug report was last modified 1 year and 264 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.