Re: Another - Bison 1.35 works but Bison 1.50 Doesn't

[Tim Van Holder]

On Mon, 2002-10-14 at 09:55, Paul Eggert wrote:
> But the warning doesn't suffice to catch such problems.  For example:
> 
>   a : a1 a2 a3 a4 ;
> 
> Suppose 'a' is untyped but 'a1' through 'a4' are typed and dynamically
> allocated.  The warning that you mention would catch 'a1', but 'a2'
> through 'a4' would go uncaught.  Furthermore, if the rule has an
> action (which is typical in real grammars), no warning will be
> generated and even 'a1' won't be caught.
> 
> It would be nice to have a memory-leak warning feature, but that would
> be a different feature, one that would require more thought.

I wasn't claiming it was warning about memory leaks, just that because
of the warning some potential memory leaks are more easily caught.
Even in the case above, the user will have to write an action because
of the warning as long as a1 is typed, making it more likely for any
leaks to be seen and plugged (leaving any leaks purely in the realm of
user error, instead of being attributable to tool silence).
Granted, more complete checking specifically for potential leaks would
be nice. Every little bit helps though, and I'm not convinced that
occasionally having to add an empty action to pacify bison is such a big
inconvenience.  It could be made into a mere warning though, so it
doesn't prevent the generation of the parser, but is still mentioned to
the user.

> > Privileged/Confidential Information may be contained in this message.
> 
> Ouch.  Can't you shut that boilerplate off?

Sure - it just defaults to that since I'm at work and I'm usually too
lazy and/or absent-minded to trim it (even though Evolution makes it
easy).  I've even been scolded by our marketing guy that my archived
posts to GNU mailing lists show up in a Google search for our company
name :-) (which is why I'm leaving the signature off entirely for this
post, and will try to remember to do that every time).