20 May
2024
20 May
'24
8:26 p.m.
On 5/20/24 9:41 AM, Ralph Corderoy wrote:
Hi Chet,
Maybe we're talking about the same thing. My impression is that at
each point there was more than one potential token to insert and go on,
and gawk chose one (probably the most common one), in the hopes that it
would be able to report as many errors as possible. There's always the
chance you'll be wrong there.
(I have no insight into the actual nature of these issues, or the actual
corruption that caused the crashes, so take the next with skepticism.)
And then rather than go back and modify other state after inserting
this token -- which gawk did not do -- for the sole purpose of making
this guessing more crash-resistant, Arnold chose a different approach:
exit on invalid input.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
Doug wrote:
That aside, having made the decision to patch up the input so more
punched cards are consumed, the patch should be bug free.
Say it's inserting a semicolon token for pretence. It should have
initialised source-file locations just as if it were real. Not an
uninitialised pointer to a source filename so a later dereference
failed.
I can see an avalanche of errors in an earlier gawk caused problems, but
each time there would have been a first patch of the input which made
a mistake causing the pebble to start rolling. My understanding is that
there was potentially a lot of these and rather than fix them it was
more productive of the limited time to stop patching the input. Then
the code which patched could be deleted, getting rid of the buggy bits
along the way?
I'm surprised by nonchalance about bad
inputs evoking bad program
behavior.
I think the claim is that it's better to stop immediately with an
error on invalid input rather than guess at the user's intent and try
to go on.