20 May
2024
20 May
'24
2:09 p.m.
Well this is obviously a hot button topic. AFAIK I was nearby when fuzz-testing for
software was invented. I was the main advocate for hiring Andy Payne into the Digital
Cambridge Research Lab. One of his little projects was a thing that generated random but
correct C programs and fed them to different compilers or compilers with different
switches to see if they crashed or generated incorrect results. Overnight, his tester
filed 300 or so bug reports against the Digital C compiler. This was met with substantial
pushback, but it was a mostly an issue that many of the reports traced to the same
underlying bugs.
Bill McKeemon expanded the technique and published "Differential Testing of
Software"
https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTesting…
Andy had encountered the underlying idea while working as an intern on the Alpha processor
development team. Among many other testers, they used an architectural tester called REX
to generate more or less random sequences of instructions, which were then run through
different simulation chains (functional, RTL, cycle-accurate) to see if they did the same
thing. Finding user-accessible bugs in hardware seems like a good thing.
The point of generating correct programs (mentioned under the term LangSec here) goes a
long way to avoid irritating the maintainers. Making the test cases short is also
maintainer-friendly. The test generator is also in a position to annotate the source with
exactly what it is supposed to do, which is also helpful.
-L
21 May
21 May
1:56 a.m.
New subject: A fuzzy awk.
Ron Hardin was doing this to Dennis's C compiler in the 1980s, well before
1998. And I believe Doug McIlroy was generating random regular expressions
to compare different implementations. It's probably impossible to decide
who invented fuzzing, so the credit will surely go to the person who named
it.
-rob
On Tue, May 21, 2024 at 12:09 AM Serissa <stewart(a)serissa.com> wrote:
Well this is obviously a hot button topic. AFAIK I
was nearby when
fuzz-testing for software was invented. I was the main advocate for hiring
Andy Payne into the Digital Cambridge Research Lab. One of his little
projects was a thing that generated random but correct C programs and fed
them to different compilers or compilers with different switches to see if
they crashed or generated incorrect results. Overnight, his tester filed
300 or so bug reports against the Digital C compiler. This was met with
substantial pushback, but it was a mostly an issue that many of the reports
traced to the same underlying bugs.
Bill McKeemon expanded the technique and published "Differential Testing
of Software"
https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTesting…
Andy had encountered the underlying idea while working as an intern on the
Alpha processor development team. Among many other testers, they used an
architectural tester called REX to generate more or less random sequences
of instructions, which were then run through different simulation chains
(functional, RTL, cycle-accurate) to see if they did the same thing.
Finding user-accessible bugs in hardware seems like a good thing.
The point of generating correct programs (mentioned under the term LangSec
here) goes a long way to avoid irritating the maintainers. Making the test
cases short is also maintainer-friendly. The test generator is also in a
position to annotate the source with exactly what it is supposed to do,
which is also helpful.
-L
2:47 a.m.
New subject: A fuzzy awk.
I think the title might go to my OS prof, Bart Miller. He did a paper
https://www.paradyn.org/papers/fuzz.pdf
that named it that in 1990.
On Tue, May 21, 2024 at 11:56:30AM +1000, Rob Pike wrote:
Ron Hardin was doing this to Dennis's C compiler
in the 1980s, well before
1998. And I believe Doug McIlroy was generating random regular expressions
to compare different implementations. It's probably impossible to decide
who invented fuzzing, so the credit will surely go to the person who named
it.
-rob
On Tue, May 21, 2024 at 12:09???AM Serissa <stewart(a)serissa.com> wrote:
> Well this is obviously a hot button topic. AFAIK I was nearby when
> fuzz-testing for software was invented. I was the main advocate for hiring
> Andy Payne into the Digital Cambridge Research Lab. One of his little
> projects was a thing that generated random but correct C programs and fed
> them to different compilers or compilers with different switches to see if
> they crashed or generated incorrect results. Overnight, his tester filed
> 300 or so bug reports against the Digital C compiler. This was met with
> substantial pushback, but it was a mostly an issue that many of the reports
> traced to the same underlying bugs.
>
> Bill McKeemon expanded the technique and published "Differential Testing
> of Software"
>
https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTesting…
>
> Andy had encountered the underlying idea while working as an intern on the
> Alpha processor development team. Among many other testers, they used an
> architectural tester called REX to generate more or less random sequences
> of instructions, which were then run through different simulation chains
> (functional, RTL, cycle-accurate) to see if they did the same thing.
> Finding user-accessible bugs in hardware seems like a good thing.
>
> The point of generating correct programs (mentioned under the term LangSec
> here) goes a long way to avoid irritating the maintainers. Making the test
> cases short is also maintainer-friendly. The test generator is also in a
> position to annotate the source with exactly what it is supposed to do,
> which is also helpful.
>
> -L
>
>
>
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
2:54 a.m.
New subject: A fuzzy awk.
Good to learn more of the history! I wonder when the technique got started on the
hardware side?
I wouldn’t be surprised if IBM were doing some of this for the S/360 since it was a nearly
compatible set of systems.
-L
On May 20, 2024, at 10:47 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
I think the title might go to my OS prof, Bart Miller. He did a paper
https://www.paradyn.org/papers/fuzz.pdf
that named it that in 1990.
On Tue, May 21, 2024 at 11:56:30AM +1000, Rob Pike wrote:
Ron Hardin was doing this to Dennis's C
compiler in the 1980s, well before
1998. And I believe Doug McIlroy was generating random regular expressions
to compare different implementations. It's probably impossible to decide
who invented fuzzing, so the credit will surely go to the person who named
it.
-rob
On Tue, May 21, 2024 at 12:09???AM Serissa <stewart(a)serissa.com> wrote:
> Well this is obviously a hot button topic. AFAIK I was nearby when
> fuzz-testing for software was invented. I was the main advocate for hiring
> Andy Payne into the Digital Cambridge Research Lab. One of his little
> projects was a thing that generated random but correct C programs and fed
> them to different compilers or compilers with different switches to see if
> they crashed or generated incorrect results. Overnight, his tester filed
> 300 or so bug reports against the Digital C compiler. This was met with
> substantial pushback, but it was a mostly an issue that many of the reports
> traced to the same underlying bugs.
>
> Bill McKeemon expanded the technique and published "Differential Testing
> of Software"
>
https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTesting…
>
> Andy had encountered the underlying idea while working as an intern on the
> Alpha processor development team. Among many other testers, they used an
> architectural tester called REX to generate more or less random sequences
> of instructions, which were then run through different simulation chains
> (functional, RTL, cycle-accurate) to see if they did the same thing.
> Finding user-accessible bugs in hardware seems like a good thing.
>
> The point of generating correct programs (mentioned under the term LangSec
> here) goes a long way to avoid irritating the maintainers. Making the test
> cases short is also maintainer-friendly. The test generator is also in a
> position to annotate the source with exactly what it is supposed to do,
> which is also helpful.
>
> -L
>
>
>
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
3:36 a.m.
New subject: A fuzzy awk.
Eventually Dennis told Ron to stop as he wasn't interested in protecting
against insane things like "unsigned register union". Now that computing
has become more adversarial, he might feel differently.
-rob
11:59 a.m.
New subject: A fuzzy awk.
On a lesser note, one day I got tired of C compiler crashes (probably
on the Vax, possibly originating in my code generator) and converted
them into 'fatal internal error' messages.
On Mon, May 20, 2024 at 11:36 PM Rob Pike <robpike(a)gmail.com> wrote:
Eventually Dennis told Ron to stop as he wasn't interested in protecting against
insane things like "unsigned register union". Now that computing has become more
adversarial, he might feel differently.
-rob
3:53 a.m.
New subject: A fuzzy awk.
On Tue, May 21, 2024 at 11:56 AM Rob Pike <robpike(a)gmail.com> wrote:
It's probably impossible to decide who invented
fuzzing, so the credit will surely go to the person who named it.
That theory probably applies to the Earl of Sandwich, And the Earl of
Cardigan. Hoare Belisha also did ok for giant orange balls at zebra
crossings. I'm less sure the Earl of Zebra feels recognised, or that
Eugène-René Poubelle feels happy with his namesake (he should do, dust
bins are huge)
4:59 p.m.
New subject: A fuzzy awk.
On Tue, May 21, 2024 at 12:09 AM Serissa <stewart(a)serissa.com> wrote:
Well this is obviously a hot button topic. AFAIK I
was nearby when
In the mid-late 1980s Bill Mckeeman worked with DEC's compiler product
teams to introduce fuzz testing into our testing process. As with the C
compiler work at DEC Cambridge, fuzz testing for other compilers (Fortran,
PL/I) also found large numbers of bugs.
The pushback from the compiler folks was mainly a matter of priorities.
Fuzz testing is very adept at finding edge conditions, but most failing
fuzz tests have syntax that no human programmer would ever write. As a
compiler engineer you have limited time to devote to bug testing. Do you
spend that time addressing real customer issues that have been reported or
do you spend it fixing problems with code that no human being would ever
write? To take an example that really happened, a fuzz test consisting of
100 nested parentheses caused an overflow in a parser table (it could only
handle 50 nested parens). Is that worth fixing?
As you pointed out, fuzz test failures tend to occur in clusters and many
of the failures eventually are traced to the same underlying bug. Which
leads to the counter-argument to the pushback. The fuzz tests are finding
real underlying bugs. Why not fix them before a customer runs into them?
That very thing did happen several times. A customer-reported bug was
fixed and suddenly several of the fuzz test problems that had been reported
went away. Another consideration is that, even back in the 1980s, humans
weren't the only ones writing programs. There were programs writing
programs and they sometimes produced bizarre (but syntactically correct)
code.
-Paul W.
fuzz-testing for software was invented. I was the
main advocate for hiring
Andy Payne into the Digital Cambridge Research Lab. One of his little
projects was a thing that generated random but correct C programs and fed
them to different compilers or compilers with different switches to see if
they crashed or generated incorrect results. Overnight, his tester filed
300 or so bug reports against the Digital C compiler. This was met with
substantial pushback, but it was a mostly an issue that many of the reports
traced to the same underlying bugs.
Bill McKeemon expanded the technique and published "Differential Testing
of Software"
https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTesting…
5:56 p.m.
New subject: A fuzzy awk.
On Tuesday, May 21st, 2024 at 9:59 AM, Paul Winalski <paul.winalski(a)gmail.com>
wrote:
On Tue, May 21, 2024 at 12:09 AM Serissa
<stewart(a)serissa.com> wrote:
A happy medium could be including far-out fuzzing to characterize issues, but not
necessarily then immediately sink the resources into resolving bizarre discoveries from
the fuzzing. Better to know then not but also have the wisdom to determine "is
someone actually going to trip this" vs. "this is something that is possible and
good to document". In my own work we have several of the latter where something is
almost guaranteed to never happen with a human interaction, but is also something we want
documented somewhere so if unlikely problem <xyz> ever does happen, the discovery is
already done and we just start plotting out a solution. That's also some nice low
hanging fruit to pluck when there isn't much else going on, but avoids the phenomenon
where we sink critical time into bugfixes with a microscopic ROI.
- Matt G.
> Well this is obviously a hot button topic.
AFAIK I was nearby when fuzz-testing for software was invented. I was the main advocate
for hiring Andy Payne into the Digital Cambridge Research Lab. One of his little projects
was a thing that generated random but correct C programs and fed them to different
compilers or compilers with different switches to see if they crashed or generated
incorrect results. Overnight, his tester filed 300 or so bug reports against the Digital C
compiler. This was met with substantial pushback, but it was a mostly an issue that many
of the reports traced to the same underlying bugs.
>
> Bill McKeemon expanded the technique and published "Differential Testing of
Software"
https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTesting…
In the mid-late 1980s Bill Mckeeman worked with DEC's compiler product teams to
introduce fuzz testing into our testing process. As with the C compiler work at DEC
Cambridge, fuzz testing for other compilers (Fortran, PL/I) also found large numbers of
bugs.
The pushback from the compiler folks was mainly a matter of priorities. Fuzz testing is
very adept at finding edge conditions, but most failing fuzz tests have syntax that no
human programmer would ever write. As a compiler engineer you have limited time to devote
to bug testing. Do you spend that time addressing real customer issues that have been
reported or do you spend it fixing problems with code that no human being would ever
write? To take an example that really happened, a fuzz test consisting of 100 nested
parentheses caused an overflow in a parser table (it could only handle 50 nested parens).
Is that worth fixing?
As you pointed out, fuzz test failures tend to occur in clusters and many of the failures
eventually are traced to the same underlying bug. Which leads to the counter-argument to
the pushback. The fuzz tests are finding real underlying bugs. Why not fix them before a
customer runs into them? That very thing did happen several times. A customer-reported bug
was fixed and suddenly several of the fuzz test problems that had been reported went away.
Another consideration is that, even back in the 1980s, humans weren't the only ones
writing programs. There were programs writing programs and they sometimes produced bizarre
(but syntactically correct) code.
-Paul W. 
6:12 p.m.
New subject: A fuzzy awk.
I like this anecdote because it points out the difference between being
able to handle and process bizarre conditions, as if they were something
that should work, which is maybe not that helpful, vs. detecting them
and doing something reasonable, like failiing with a "limit exceeded"
message. A silent, insidious failure down the line because a limit was
exceeded is never good. If "fuzz testing" helps exercise limits and
identifies places where software hasn't realized it has exceeded its
limits, has run off the end of a table, etc., that seems like a good
thing to me.
On 05/21/2024 09:59 AM, Paul Winalski wrote:
On Tue, May 21, 2024 at 12:09 AM Serissa
<stewart(a)serissa.com
<mailto:stewart@serissa.com>> wrote:
Well this is obviously a hot button topic. AFAIK I was nearby
when fuzz-testing for software was invented. I was the main
advocate for hiring Andy Payne into the Digital Cambridge
Research Lab. One of his little projects was a thing that
generated random but correct C programs and fed them to
different compilers or compilers with different switches to
see if they crashed or generated incorrect results.
Overnight, his tester filed 300 or so bug reports against the
Digital C compiler. This was met with substantial pushback,
but it was a mostly an issue that many of the reports traced
to the same underlying bugs.
Bill McKeemon expanded the technique and published
"Differential Testing of Software"
https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTesting…
<https://www.cs.swarthmore.edu/%7Ebylvisa1/cs97/f13/Papers/DifferentialTestingForSoftware.pdf>
In the mid-late 1980s Bill Mckeeman worked with DEC's compiler product
teams to introduce fuzz testing into our testing process. As with the
C compiler work at DEC Cambridge, fuzz testing for other compilers
(Fortran, PL/I) also found large numbers of bugs.
The pushback from the compiler folks was mainly a matter of
priorities. Fuzz testing is very adept at finding edge conditions,
but most failing fuzz tests have syntax that no human programmer would
ever write. As a compiler engineer you have limited time to devote to
bug testing. Do you spend that time addressing real customer issues
that have been reported or do you spend it fixing problems with code
that no human being would ever write? To take an example that really
happened, a fuzz test consisting of 100 nested parentheses caused an
overflow in a parser table (it could only handle 50 nested parens).
Is that worth fixing?
As you pointed out, fuzz test failures tend to occur in clusters and
many of the failures eventually are traced to the same underlying
bug. Which leads to the counter-argument to the pushback. The fuzz
tests are finding real underlying bugs. Why not fix them before a
customer runs into them? That very thing did happen several times. A
customer-reported bug was fixed and suddenly several of the fuzz test
problems that had been reported went away. Another consideration is
that, even back in the 1980s, humans weren't the only ones writing
programs. There were programs writing programs and they sometimes
produced bizarre (but syntactically correct) code.
-Paul W.
22 May
22 May
3:37 p.m.
New subject: A fuzzy awk.
On Tue, May 21, 2024 at 2:12 PM Luther Johnson <luther.johnson(a)makerlisp.com>
wrote:
I like this anecdote because it points out the
difference between being
able to handle and process bizarre conditions, as if they were something
that should work, which is maybe not that helpful, vs. detecting them and
doing something reasonable, like failiing with a "limit exceeded" message
That is in fact precisely how the DEC compiler handled the 100 nested
parentheses condition.
. A silent, insidious failure down the line because a
limit was exceeded
is never good.
Amen! One should always do bounds checking when dealing with fixed-size
aggregate data structures. One compiler that I worked on got a bug report
of bad code being generated. The problem was an illegal optimization that
never should have triggered but did due to a corrupted data table. Finding
the culprit of the corruption took hours. It finally turned out to be due
to overflow of an adjacent data table in use elsewhere in the compiler.
The routine to add another entry to that table didn't check for table
overflow.
-Paul W.
6:49 p.m.
New subject: A fuzzy awk.
On Wed, May 22, 2024 at 11:37:39AM -0400, Paul Winalski wrote:
On Tue, May 21, 2024 at 2:12???PM Luther Johnson
<luther.johnson(a)makerlisp.com>
wrote:
We invented a data structure that gets around this problem nicely. It's
an array of pointers that starts at [1] instead of [0]. The [0]
entry encodes 2 things:
In the upper bits, the log(2) the size of the array. So all arrays
have at least [0] and [1]. So 2 pointers is the smallest array and
that was important to us, we wanted it to scale up and scale down.
In the lower bits, we record the number of used entries in the array.
We assumed 32 bit pointers and with those we got ~134 million entries
as our maximum number of entries.
Usage is like
char **space = allocLines(4); // start with space for 4 entries
space = addLine(space, "I am [1]");
space = addLine(space, "I am [2]");
space = addLine(space, "I am [3]");
space = addLine(space, "I am [4]"); // realloc's to 8 entries
freelines(space, 0); // second arg is typically 0 or free()
It works GREAT. We used it all over BitKeeper, for stuff as small as
commit comments to arrays of data structures. It scales down, scales
up. Helper functions:
/*
* liblines - interfaces for autoexpanding data structures
*
* s= allocLines(n)
* pre allocate space for slightly less than N entries.
* s = addLine(s, line)
* add line to s, allocating as needed.
* line must be a pointer to preallocated space.
* freeLines(s, freep)
* free the lines array; if freep is set, call that on each entry.
* if freep is 0, do not free each entry.
* buf = popLine(s)
* return the most recently added line (not an alloced copy of it)
* reverseLines(s)
* reverse the order of the lines in the array
* sortLines(space, compar)
* sort the lines using the compar function if set, else string_sort()
* removeLine(s, which, freep)
* look for all lines which match "which" and remove them from the array
* returns number of matches found
* removeLineN(s, i, freep)
* remove the 'i'th line.
* lines = splitLine(buf, delim, lines)
* split buf on any/all chars in delim and put the tokens in lines.
* buf = joinLines(":", s)
* return one string which is all the strings glued together with ":"
* does not free s, caller must free s.
* buf = findLine(lines, needle);
* Return the index the line in lines that matches needle
*/
It's all open source, apache licensed, but you'd have to tease it out of
the bitkeeper source tree. Wouldn't be that hard and it would be useful.
I like this anecdote because it points out the
difference between being
able to handle and process bizarre conditions, as if they were something
that should work, which is maybe not that helpful, vs. detecting them and
doing something reasonable, like failiing with a "limit exceeded" message
That is in fact precisely how the DEC compiler handled the 100 nested
parentheses condition.
. A silent, insidious failure down the line
because a limit was exceeded
is never good.
Amen! One should always do bounds checking when dealing with fixed-size
aggregate data structures. One compiler that I worked on got a bug report
of bad code being generated. The problem was an illegal optimization that
never should have triggered but did due to a corrupted data table. Finding
the culprit of the corruption took hours. It finally turned out to be due
to overflow of an adjacent data table in use elsewhere in the compiler.
The routine to add another entry to that table didn't check for table
overflow.
8:17 p.m.
New subject: A fuzzy awk.
Wayne teased this into a stand alone library here:
https://github.com/wscott/bksupport
On Wed, May 22, 2024 at 11:49:04AM -0700, Larry McVoy wrote:
On Wed, May 22, 2024 at 11:37:39AM -0400, Paul
Winalski wrote:
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
On Tue, May 21, 2024 at 2:12???PM Luther Johnson
<luther.johnson(a)makerlisp.com>
wrote:
We invented a data structure that gets around this problem nicely. It's
an array of pointers that starts at [1] instead of [0]. The [0]
entry encodes 2 things:
In the upper bits, the log(2) the size of the array. So all arrays
have at least [0] and [1]. So 2 pointers is the smallest array and
that was important to us, we wanted it to scale up and scale down.
In the lower bits, we record the number of used entries in the array.
We assumed 32 bit pointers and with those we got ~134 million entries
as our maximum number of entries.
Usage is like
char **space = allocLines(4); // start with space for 4 entries
space = addLine(space, "I am [1]");
space = addLine(space, "I am [2]");
space = addLine(space, "I am [3]");
space = addLine(space, "I am [4]"); // realloc's to 8 entries
freelines(space, 0); // second arg is typically 0 or free()
It works GREAT. We used it all over BitKeeper, for stuff as small as
commit comments to arrays of data structures. It scales down, scales
up. Helper functions:
/*
* liblines - interfaces for autoexpanding data structures
*
* s= allocLines(n)
* pre allocate space for slightly less than N entries.
* s = addLine(s, line)
* add line to s, allocating as needed.
* line must be a pointer to preallocated space.
* freeLines(s, freep)
* free the lines array; if freep is set, call that on each entry.
* if freep is 0, do not free each entry.
* buf = popLine(s)
* return the most recently added line (not an alloced copy of it)
* reverseLines(s)
* reverse the order of the lines in the array
* sortLines(space, compar)
* sort the lines using the compar function if set, else string_sort()
* removeLine(s, which, freep)
* look for all lines which match "which" and remove them from the array
* returns number of matches found
* removeLineN(s, i, freep)
* remove the 'i'th line.
* lines = splitLine(buf, delim, lines)
* split buf on any/all chars in delim and put the tokens in lines.
* buf = joinLines(":", s)
* return one string which is all the strings glued together with ":"
* does not free s, caller must free s.
* buf = findLine(lines, needle);
* Return the index the line in lines that matches needle
*/
It's all open source, apache licensed, but you'd have to tease it out of
the bitkeeper source tree. Wouldn't be that hard and it would be useful. I like this anecdote because it points out the
difference between being
able to handle and process bizarre conditions, as if they were something
that should work, which is maybe not that helpful, vs. detecting them and
doing something reasonable, like failiing with a "limit exceeded" message
That is in fact precisely how the DEC compiler handled the 100 nested
parentheses condition.
. A silent, insidious failure down the line
because a limit was exceeded
is never good.
Amen! One should always do bounds checking when dealing with fixed-size
aggregate data structures. One compiler that I worked on got a bug report
of bad code being generated. The problem was an illegal optimization that
never should have triggered but did due to a corrupted data table. Finding
the culprit of the corruption took hours. It finally turned out to be due
to overflow of an adjacent data table in use elsewhere in the compiler.
The routine to add another entry to that table didn't check for table
overflow. 
3:26 a.m.
New subject: A fuzzy awk.
On Tue, 21 May 2024, Paul Winalski wrote:
To take an example that really happened, a fuzz test
consisting of 100
nested parentheses caused an overflow in a parser table (it could only
handle 50 nested parens). Is that worth fixing?
Well, they could be a rabid LISP programmer...
-- Dave
5:08 a.m.
New subject: A fuzzy awk.
Dave Horsfall <dave(a)horsfall.org> writes:
On Tue, 21 May 2024, Paul Winalski wrote:
Just did a quick check of some of the ELisp packages on my system:
* For my own packages, the maximum was 10 closing parentheses.
* For the packages in my elpa/ directory, the maximum was 26 in
ducpel-glyphs.el, where they were part of a glyph, rather than
delimiting code. The next highest value was 16, in org.el and
magit-sequence.el.
i would suggest that any Lisp with more than a couple of dozen
closing parentheses is in dire need of refactoring. Although of
course someone who's rabid is probably not in the appropriate
mental state for that. :-)
Alexis.
To take an example that really happened, a fuzz
test consisting
of 100
nested parentheses caused an overflow in a parser table (it
could only
handle 50 nested parens). Is that worth fixing?
Well, they could be a rabid LISP programmer... 
1:12 p.m.
New subject: A fuzzy awk.
On Tue, May 21, 2024, 11:08 PM Alexis <flexibeast(a)gmail.com> wrote:
Dave Horsfall <dave(a)horsfall.org> writes:
That's what ']' is for.
Warner
On Tue, 21 May 2024, Paul Winalski wrote:
Just did a quick check of some of the ELisp packages on my system:
* For my own packages, the maximum was 10 closing parentheses.
* For the packages in my elpa/ directory, the maximum was 26 in
ducpel-glyphs.el, where they were part of a glyph, rather than
delimiting code. The next highest value was 16, in org.el and
magit-sequence.el.
i would suggest that any Lisp with more than a couple of dozen
closing parentheses is in dire need of refactoring. Although of
course someone who's rabid is probably not in the appropriate
mental state for that. :-)
To take an example that really happened, a fuzz
test consisting
of 100
nested parentheses caused an overflow in a parser table (it
could only
handle 50 nested parens). Is that worth fixing?
Well, they could be a rabid LISP programmer...
120
days inactive
122
days old
15 comments
12 participants
participants (12)
-
Alexis -
Dave Horsfall -
George Michaelson -
Larry McVoy -
Lawrence Stewart -
Luther Johnson -
Paul Winalski -
Peter Weinberger (温博格) -
Rob Pike -
segaloco -
Serissa
-
Warner Losh