On Mon, Jul 28, 2025 at 12:32 AM Lynn Winebarger <owinebar@gmail.com> wrote:
>
> On Sat, Jul 26, 2025 at 12:00 PM Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
> >
> > >> BTW memory that's not returned to the OS but that Emacs can reuse
> > >> later is generally not considered as a leak.  E.g., most `malloc`
> > >> implementations have the property of (virtually) never bothering to
> > >> return freed memory to the OS.
> > > Terminology aside, the memory used for the stack is never freed for
> > > use by other parts of Emacs.
> >
> > Yup.  Still not considered a leak.  🙁
> > It may be a waste of memory, of course, but we use similar approaches in
> > other places without worrying very much about it.  For example, we grow
> > hashtables on-demand in `puthash`, but we never shrink them back in
> > `remhash`.
> >
> > That doesn't mean I'm opposed to changing the read code to be more
> > careful with its use of memory, but I don't consider it a serious
> > concern, so code clarity, speed, reentrancy, and things like that are
> > more important.
>
> Ok, the attached patch bootstraps with -O0 without native compilation.
> I haven't done any benchmarking or tuning, or tested with optimization
> turned on, but it shows the technique.  The changes don't seem to have
> leaked beyond the obviously required scope.  The patch does eliminate
> one unwind_protect (per entry to read0) which is made unnecessary by
> using alloca.
>
This version eliminates the trampoline function and uses C block scope
and goto in place of return/call.  I have no idea if C semantics
guarantee the assumptions about jumping out of block scope and
variables allocated on the stack.  It seems to work with -O0.

Lynn