> : The best long-term solution for this problem is to write a new backend
 > : for gcc that emits K&R C, and treat the old compiler as the assembler
 > : pass. Then you can use those archaic compilers if you have to (that
 > : is, until the gcc port is ready) without kludging up the source.
 > 
 > See `unprotoize.'

Since three people said this... last I remember unprotoize wasn't
perfect; also, a real backend would let you compile anything you had a
gcc frontend for (c++, objc, java, pascal, ada, whatnot). And,
arguably, it's less likely to generate bad code. But unprotoize is
probably enough for NetBSD. :-)

The pros and cons of this, however, are off topic; the point was that
there are adequate solutions that don't involve holding the source
tree in the dark ages.

-- 
   - David A. Holland             |
     dholland@cs.utoronto.ca      |