Re: Languages that are hard to parse

ralph@inputplus.co.uk (Ralph Corderoy)
26 May 2005 23:09:05 -0400

          From comp.compilers
Related articles
[8 earlier articles]
Re: Languages that are hard to parse gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-05-22)
Re: Languages that are hard to parse Satyam@satyam.com.ar (Satyam) (2005-05-22)
Re: Languages that are hard to parse DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-22)
Re: Languages that are hard to parse dot@dotat.at (Tony Finch) (2005-05-24)
Re: Languages that are hard to parse wclodius@lanl.gov (2005-05-24)
Re: Languages that are hard to parse Martin.Ward@durham.ac.uk (Martin Ward) (2005-05-24)
Re: Languages that are hard to parse ralph@inputplus.co.uk (2005-05-26)
Re: Languages that are hard to parse hannah@schlund.de (2005-06-02)
Re: Languages that are hard to parse zvr@pobox.com (Alexios Zavras) (2005-06-02)
Re: Languages that are hard to parse gene@abhost.us (Gene Wirchenko) (2005-06-04)
| List of all articles for this month |
From: ralph@inputplus.co.uk (Ralph Corderoy)
Newsgroups: comp.compilers
Date: 26 May 2005 23:09:05 -0400
Organization: Compilers Central
References: 05-05-119 05-05-192 05-05-196 05-05-210
Keywords: debug, practice
Posted-Date: 26 May 2005 23:09:05 EDT

Hi Martin,


> The modern substitute of the card recycling bin is the cvs
> repository or RCS directories or whatever. A simple perl script can
> pick random lines from random files to create a program and feed it
> to the compiler. Repeat until the compiler segfaults or hangs.


A Markov chain based generator, fed real source code, is another good
way to produce near valid source.


Cheers,


--
Ralph Corderoy. http://inputplus.co.uk/ralph/ http://troff.org/

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.