Re: master 669aeaf: Prefer make_nil_vector to make-vector with nil

[Pip Cet]

On Wed, Aug 12, 2020 at 12:01 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> > I'd say we cut down the complication and use
> > Fmake_vector almost everywhere
>
> Although we could simplify somewhat, using Fmake_vector everywhere would go 
> too
> far. It's useful to know one needn't worry about invalid args when calling the
> proper make-vector variant. I found this useful when checking Emacs for
> undefined behavior on integer overflow; for example, 'Fmake_vector 
> (make_fixnum
> (n), ...)' won't do if n is out of range for fixnum. And an uninitialized
> variant is also worthwhile, to avoid initializing vectors twice.

I'm not sure whether it's really worthwhile to do that, because bugs
like the one we currently have in fns.c (Fdelete allocates an
uninitialized vector, then calls Fequal, which can call quit, leaving
a half-initialized vector on the stack and potentially marked by
conservative GC) are bound to bite us one day: successions of unlikely
but possible events leading to rare crashes. Particularly for
small-ish fixed-size vectors, it seems to me uninitialized vectors are
more trouble than they're worth (in fact, I could see make_vector (n,
Qnil) being faster on many CPUs, because the cache lines are written
to completely and don't have to be brought in from RAM. I'm pretty
sure CPU write buffers used to work that way, at least ...).

Of the 40 places in *.c that use make_uninit_vector, only three look
like there might be a tangible benefit: alloc.c, fns.c, and pdumper.c
(but looking over that last one, I don't understand how
hash_table_contents is functionally different from Fcopy_sequence
(h->key_and_value) at this point, with the obvious mutation in
hash_table_rehash).

0001-Fix-potential-GC-bug-in-Fdelete.patch
Description: Source code patch