GNU bug report logs -
#78898
Make read/readevalloop reentrant
Previous Next
Full log
Message #116 received at 78898 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Jul 28, 2025 at 8:09 PM Lynn Winebarger <owinebar <at> gmail.com> wrote:
> If you look at the code after applying all three patches, I think the
> code is actually simpler, and possibly faster. I can add guard rails
> for dealing with the risk of stack overflow. If you really need to
> support unbounded expression depth, I can special case allocation of
> stack to handle extraordinarily deep expressions. However, I'm not
> sure how much benefit there is to being able to process an ELC file
> that has a correct header followed by, say a million left parentheses
> and then the EOF. If a user wants to handle such outliers, I think
> they can be handled without the level of performance provided for more
> realistic cases. For example, by allocating a memory segment with
> one read stack entry for every byte of the input file to use as the
> read stack.
I reviewed the material on storage duration in C on cppreference.com.
Except for variable length arrays, the storage of objects in variables
is determined on block entry, not at the declaration. As long as no
VLAs are declared in the function scope past the read_obj label, the
block scope wrapping the code from that label to the end is
unnecessary. So I removed that, reverted the whitespace changes, and
squashed it all into one change.
Without the added block scope, the change becomes very simple. No
new test failures (relative to the baseline commit of master) have
been added. I can add a slow path for the case where the stack is
almost overflowing or the input is just ridiculously complicated. For
files being loaded, I'd prefer to add a different source type that
either memory maps the file or slurps it into memory so we can safely
gauge a worst-case size for the slow path. A similar approach would
apply to buffers, since they are already in memory. For other stream
types being read, I think erroring out on expressions that would
overflow the stack is reasonable, given I can build emacs and run all
the tests without an overflow. Stefan's preferred benchmark technique
would be problematic though. It would almost certainly either
overflow or take the slow path.
I haven't rebased my development branch to the updates in lread.c on
master this morning. I evidently don't understand how to maintain the
bare clone I made of the emacs repo to let myself use multiple local
working trees.
[0001-Simplify-the-read-stack.patch (text/x-patch, attachment)]
This bug report was last modified 12 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.