Subject: bug#75551: Potentially erroneous long loop in lrealloc

From: Paul Eggert <[email-masked]>
Date: Tue, 14 Jan 2025 13:04:49 -0800

On 2025-01-13 19:34, Eli Zaretskii wrote:
>> Consider a host where MALLOC_IS_LISP_ALIGNED is false and p %
>> LISP_ALIGNMENT is frequently nonzero. if lrealloc is called with size
>> being a multiplier of LISP_ALIGNMENT, the loop can take a long time to
>> end until p % LISP_ALIGNMENT == 0, potentially until OOM.
>>
>> Based on my understanding, this part is to address some "oddball" hosts
>> (based on the comment in alloc.c). But this does seem like a bug to me
>> if Emacs is running on such an oddball host...
> Paul, could you please comment on this?

As far as we know, there are no oddball hosts.

If Emacs is ever built on an oddball host, the code will operate 
correctly albeit possibly very inefficiently (perhaps including unwanted 
memory exhaustion).

Alternatively, the code could simply run emacs_abort() instead of 
retrying the allocation. There should be no difference on today's 
platforms so it's no big deal either way.

Or we could even remove the runtime test entirely, i.e., remove lrealloc 
and simply call realloc. That would make Emacs a bit faster in Lisp 
allocation.