^C leak

^C leak

[Byron Rakitzis]

It appears to be in yacc.

Some yacc's call malloc to create their token stack, while some yacc's
have a fixed stack size. Now, rc calls yyparse which calls yylex which
calls read. An interrupt in read causes the signal to be trapped before
any more tokens can be returned to yacc so that it may either call
YYABORT or YYACCEPT (the two macros which also free up the yacc stack
space).

Obviously, the reason why the leak is not apparent at any time but when
a command is being typed is because the interrupt must occur while yacc
is active.

I would argue that this is a bug in yacc, given that it's extremely
difficult, if not impossible, to do exception processing given this
model. Perhaps yacc should supply a callback function to free memory,
or perhaps it should not call malloc in the first place. I'll see what
I can do about working around this. The fix is probably odious:
exception handling will have to be context-sensitive ("are we in a
stack frame containing yyparse?") and there will have to be some
automagical way of simulating a ^C through yacc. As I said, I don't
know if it's possible to fix.

In the meantime, you can always get rid of the leak by compiling rc
with a yacc that does not use malloc.  (old berkeley yacc is definitely
one of these, and it's probably in the bsd-sources tree. I got my
y.tab.c from a NeXT running such a yacc)

Depressing, eh? Does anyone have any better ideas?

Re: ^C leak

[Scott Schwartz]

I suggest not altering rc unnecessarily.  Given that there are lots of
yacc implementations floating around, including a public domain one
from corbett@berkeley.edu, you might as well just tell people to use
one of those.  If you ship a y.tab.[ch] with rc, it may not be
necessary to run yacc at all.