On Sun, May 19, 2024, 9:19 PM <arnold(a)skeeve.com> wrote: Awk bailing out near line 1. Warner

Hi Arnold, This is the first time I've heard of making life difficult for fuzzers so I'm curious... I'm assuming you agree the eventual core dump was a bug somewhere to be fixed, and probably was. Stopping on the first error lessens the ‘attack surface’ for the fuzzer. Do you think there remains a bug which would bite a user which the fuzzer might have found more easily before the shrunken surface? -- Cheers, Ralph.

On 5/20/24 5:20 AM, Ralph Corderoy wrote: It's not making life difficult for them -- they can still fuzz all they want. Chances are better they'll find a genuine bug if you stop right away. Chances are small. (People fuzz bash all the time, and that is my experience.) Look at it this way. Free Software maintainers have limited resources. Is it better to spend time on bugs that will affect a larger percentage of the user population, instead of those that require artificial circumstances that won't be encountered by normal usage? Those get pushed down on the priority list. Chet -- ``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/

On 5/20/24 9:30 AM, Ralph Corderoy wrote: I think the question is whether they were bugs in gawk at all, or the result of gawk trying to be helpful by guessing at the script's intent and trying to go on. Arnold's reaction to that, which had these negative effects most often as the result of fuzzing attempts, was to exit on the first syntax error. Would those `bugs' have manifested themselves if gawk hadn't tried to do this? Are they bugs at all? Guessing at intent is bound to be wrong some of the time, and cause errors of its own. I'm saying that fuzzing does occasionally find obscure bugs -- bugs that would never be encountered in normal usage -- and those should be fixed. Eventually. -- ``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/

I was going to keep silent on this one until I realized I disagree with both Doug and Rob here (always a little dangerous). But because of personal experience, I have a pretty strong opinion is not really a win. Note that I cribbed this email response from an answer I wrote on Quora to the question: *When you are programming and commit a minor error, such as forgetting a semicolon, the compiler throws an error and makes you fix it for yourself. Why doesn’t it just fix it by itself and notify you of the fix instead?* FWIW: The first version of the idea that I now about was DWIM - *Do What I Mean* feature from BBN’s LISP (that eventually made it into InterLISP). As the Wikipedia page describes DWIM became known as "Damn Warren's Infernal Machine" [more details in the DWIM section of the jargon file]. As Doug points out, the original Pascal implementation for Unix, pix(1), also supported this idea of fixing your code for you, and as Rob points out, UCB’s pix(1) took the idea of trying to keep going and make the compile work from the earlier Cornell PL/C compiler for the IBM 360[1], which to quote Wikipedia: “The PL/C compiler had the unusual capability of never failing to compile The problem is that people can be lazy, and instead of using " DWIM" as a tool to speed up their development and fix their own errors, they just ignore the errors. In fact, when we were teaching the “Intro to CS” course at UCB in the early 1980s; we actually had students turn in programs that had syntax errors in them because pix(1) had corrected their code -- instead of the student fixing his/her code before handing the program into the TA (and then they would complain when they got “marked down” on the assignment — sigh). IMO: All in all, the experiment failed because many (??most??) people really don’t work that way. Putting a feature like this in an IDE or even an editor like emacs might be reasonable since the sources would be modified, but it means you need to like using an IDE. I also ask --> what happens when the computer’s (IDE) guess is different from the programmer's real intent, and since it was ‘fixed’ behind the curtain, you don’t notice it? Some other people have suggested that DWIM isn’t a little like spelling ‘auto-correct’ or tools like ‘Grammarly.’ The truth is, I have a love/hate relationship with auto-correct, particularly on my mobile devices. I'm dyslexic, so tools like this can be helpful to me sometimes, but I spend a great deal of my time fighting these types of tools because they are so often wrong, particularly with a small screen/keyboard, that it is just “not fun.” This brings me back to my experience. IMO, auto-correct for programming is like DWIM all over again, and the cure causes more problems than it solves. Clem [1] I should add that after Cornell’s PL/C compiler was introduced, IBM eventually added a similar feature to its own PL/1, although it was not nearly as extensive as the Cornell solution. I’m sure you can find people who liked it, but in both cases, I personally never found it that useful. ᐧ

It appears that Clem Cole <clemc(a)ccc.com> said: PL/C was a long time ago in the early 1970s. People used it on batch systems whre you handed in your cards at the window, waited a while, and later got your printout back. Or at advanced places, you could run the cards through the reader yourself, then wait until the batch ran. In that environment, the benefit from possibly guessing an error correction right meant fewer trips to the card reader. In my youth I did a fair amount of programming that way in WATFOR/WATFIV and Algol W where we really tried to get the programs right since we wanted to finish up and go home. When I was using interactive systems where you could fix one bug and try again, over and over, it seemed like cheating. R's, John

On 2024-05-19 20:58, Rob Pike wrote: Possibly way off topic but Toronto allowed anyone to run PL/C decks for free, which I often did. One day, they decided to allow all of the card to be read as text and my card numbers generated all sorts of errors. (At least easily fixed by a visit the card punch.) S.