[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pip Cet
Subject: Re: master 669aeaf: Prefer make_nil_vector to make-vector with nil
Date: Wed, 12 Aug 2020 13:05:17 +0000

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]