On Mon, Jul 28, 2025 at 7:57 AM Mattias Engdegård wrote: > > 24 juli 2025 kl. 00.53 skrev Lynn Winebarger : > > > (1) Just reserve a conservatively large amount of stack space at the start and abort if it's exceeded. A lisp variable could be used to let the user change the size of the reserved space between activations of read0, like the maximum lisp recursion depth. > > > > (2). Allocate an array in the C stack on entry to read0 for the reader stack. During the parse, if all array entries are used, just use C recursion to call read0. > > > > (3) Reverse the order of call and return in the recursion of option (2). Meaning, enter read0 with a trampoline that allocates the reader stack with alloca. On entry to the read_obj label, check that there is enough stack space for the maximum number of entries that can be pushed before control returns to read_obj. If there is not enough space, return to the trampoline. The trampoline calls read0 in a do...while loop as long as the stack is nonempty, then returns. Since the read stack is implemented in a simple trampoline function, each alloca just extends the initial reader stack array, so growing that array never requires copying. > The attached patch set implements what I described as option (3') in the original email. I've tested the resulting code both with and without native compilation at -O0, and without native compilation at the default optimization level, and no new test failures are introduced (versus commit e3380ed6db7a1c1574c4b39d58f9200a3ffab). In fact one test failure went away in one of the configurations, though I have no idea why. It implements > Thank you, but it's not quite what we had in mind so I think we'll pass on that for now. > > More generally, it's not entirely clear what concrete problem you are actually trying to solve. Well, this is the first time in my adult life I haven't had an employer claiming to own every idea or even potential production of intellectual property regardless of whether it is properly in the course of employment, so I'm letting myself have some fun with a program I've liked for most of that adult life. So, there's no simple concrete problem beyond the statement of the bug itself. I think Stefan had my number on that. But, I do have a number of ideas for longer term projects to improve my favorite editor, like making the lisp machine more concurrency friendly. For example, eliminating static variables/global state is part of that, and the reader ecosystem seems like a good place for me to start. I also want to add lisp objects for capturing grammatical structure at a more abstract level than tree-sitter (e.g. supporting an updated Semantic framework), and integrating the construction of such objects into the lisp reader would be one project. 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. Lynn