On Mon, Jul 28, 2025 at 8:09 PM Lynn Winebarger 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.