Re: marking mystery code

Mitchell Perilstein <>
16 Feb 1996 23:45:50 -0500

          From comp.compilers

Related articles
Re: marking mystery code (1996-02-13)
Re: marking mystery code (Ted Dennison) (1996-02-14)
Re: marking mystery code (1996-02-14)
Re: marking mystery code (1996-02-16)
Re: marking mystery code (1996-02-16)
Re: marking mystery code (Mitchell Perilstein) (1996-02-16)
Re: marking mystery code (Toon Moene) (1996-02-16)
Re: marking mystery code (1996-02-17)
Re: marking mystery code (1996-02-19)
Re: marking mystery code (James Kanze US/ESC 60/3/141 #40763) (1996-02-21)
Re: marking mystery code (1996-02-24)
| List of all articles for this month |

From: Mitchell Perilstein <>
Newsgroups: comp.compilers
Date: 16 Feb 1996 23:45:50 -0500
Organization: Compilers Central
References: 96-02-168
Keywords: GCC

> I can speak from personal experience working with the FSF code. It is
> generally bloated, difficult (read: impossible) to read, uncommented,
> and much of it is totally unmaintainable.

I will try to defend the FSF here, since no one else has yet.

Yes, GCC and Emacs are difficult to maintain because of the code
style. But some other code from the FSF reads, quite literally, like
a book. Check out Bash, for prime example. Most identifiers are
multiple descriptive words; comments on all file locals and all
functions, low cyclic count, etc. So GNU tool maintainability is
spotty, it's true.

But let's talk about the effectiveness of the systems. As proof of
the GNU concept, check out "Fuzz Revisited: a Re-examination of the
Reliability of UNIX Utilities and Services," by Barton Miller
<> et al at U of WI CS. (Anyone know where it was
published? I just have a prelim paper dated 4/95.) Anyway, they
tested several UNIX implementations for reliability of their programs
under unexpected conditions. They concluded that GNU and Linux
utilities (Linux utilities are almost all GNU) had noticably better
reliability than commercial 1995 UNIXes. The percentages of tools
which crashed or hung were: SunOS 23, HP-UX 18, AIX 20, Solaris 23,
Irix 15, Ultrix 21, NEXT 43, GNU 7, Linux 9.

The reason GNU and Linux are so low, they speculated, is because users
often fix their own bugs and send them back to the authors--who are
identified in the source--increasing the next version's robustness.
My point is, whatever they're doing, it works, because the user base
has demonstrated that it can maintain effectively. Now, if all the
code was easy to read, maybe they would have an even better showing.
  Mitchell N. Perilstein [\]
  COMPASS Design Automation, Columbia MD USA
  Tel: 301-724-5938, Fax: 410-992-3536

Post a followup to this message

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