Re: marking mystery code

> 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
<bart@cs.wisc.edu> 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
  mnp@compass-da.com
  Tel: 301-724-5938, Fax: 410-992-3536
--

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