Fix undefined behavior in maybe_resize_hash_table

Problem discovered with GCC 16.1.1 -fsanitize=undefined.
* src/fns.c (maybe_resize_hash_table): Avoid undefined
behavior when h->key_and_value or h->hash are null pointers,
in which case we call memcpy (destination, NULL, 0)
which has undefined behavior in C89 through C23.
This commit is contained in:
Paul Eggert 2026-05-17 22:49:44 -07:00
parent 7587bb2654
commit 07fe0b297b

View file

@ -4975,13 +4975,15 @@ maybe_resize_hash_table (struct Lisp_Hash_Table *h)
Lisp_Object *key_and_value
= hash_table_alloc_bytes (2 * new_size * sizeof *key_and_value);
memcpy (key_and_value, h->key_and_value,
2 * old_size * sizeof *key_and_value);
if (old_size)
memcpy (key_and_value, h->key_and_value,
2 * old_size * sizeof *key_and_value);
for (ptrdiff_t i = 2 * old_size; i < 2 * new_size; i++)
key_and_value[i] = HASH_UNUSED_ENTRY_KEY;
hash_hash_t *hash = hash_table_alloc_bytes (new_size * sizeof *hash);
memcpy (hash, h->hash, old_size * sizeof *hash);
if (old_size)
memcpy (hash, h->hash, old_size * sizeof *hash);
ptrdiff_t old_index_size = hash_table_index_size (h);
ptrdiff_t index_bits = compute_hash_index_bits (new_size);