bug#65491: [PATCH] Improve performance allocating vectors

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Even converting them back to their original pointer (which is what we do
>>> with tag/untag pairs) is documented to be well-defined if you compile
>>> using GCC.
>> Only if the consequent pointer designates the same object as the initial
>> pointer (of which I see no scrutable definition within GCC's
>> documentation.)
>
> IIUC the "if" here is talking about the fact that if the object is
> deallocated between the two casts, then you're on your own, of course.

Nope, (gcc)Arrays and Pointers is quite unequivocal:

   * `The result of converting a pointer to an integer or vice versa
     (C90 6.3.4, C99 and C11 6.3.2.3).'

     A cast from pointer to integer discards most-significant bits if
     the pointer representation is larger than the integer type,
     sign-extends(1) if the pointer representation is smaller than the
     integer type, otherwise the bits are unchanged.

     A cast from integer to pointer discards most-significant bits if
     the pointer representation is smaller than the integer type,
     extends according to the signedness of the integer type if the
     pointer representation is larger than the integer type, otherwise
     the bits are unchanged.

     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.

and directly cites the apposite portions of the Standard.

> IIUC Mattias bumped into this after he made a few "innocent looking"
> changes to the vector allocation code.

I'll let Mattias fill us in.