Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| From: | gah4 <gah4@u.washington.edu> |
| Newsgroups: | comp.compilers |
| Date: | Fri, 21 Oct 2022 16:56:37 -0700 (PDT) |
| Organization: | Compilers Central |
| References: | 22-10-029 22-10-031 22-10-035 22-10-036 22-10-039 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="74260"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | history, comment |
| Posted-Date: | 21 Oct 2022 20:19:58 EDT |
| In-Reply-To: | 22-10-039 |
On Friday, October 21, 2022 at 4:46:28 PM UTC-7, Thomas Koenig wrote:
(snip)
> Traditionally, internal compiler errors on invalid code have been
> considered relatively easy. But you may always find a hard one...
Reminds me of the story (I never saw anyone do it) that in the early days
of compilers, they would feed cards from the card recycle bin to them.
That is, as you note, a test of (most likely) invalid code.
But now that we don't have card recycle bins, where do you get a good
selection of invalid code to test them with?
[I've seen reports where people fed strings of random bytes into various
kinds of programs to see what happened. Almost invariably they crashed.
On the other hand, I recall a story from the 1960s in which someone reported
that an IBM Fortran compiler failed on a source card that contained an
obscure hard to punch invalid special character which they happened to use
for an internal delimiter. The quite reasonable reply was "Don't do that."
-John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.