>>> I had to fix or hack around at least 2 "serious" gcc bugs when i
>>> got started making gcc compile NetBSD/Alpha.
>> Fine, but why is "unproto" an unacceptable alternative during the
>> bootstrap process?
> Can we just put this to rest?  I mean, don't we have more important
> things to argue about?

Apparently not :-/

> (PS, I for one, don't want to go through the tree and remove every
> bloody __P(), especially when I find them useful.)

I don't think anyone's been advocating that; I certainly haven't.  My
position is that we should stop requiring new code to use __P(()) for
prototypes and old-style definitions; perhaps we should require fully
prototyped code, perhaps we should merely accept it.  (Actually, I'd
prefer the latter, since I still kinda want to see my tar accepted, and
it's one of the few programs I still maintain old-style, because for it
I do care about portability to pre-ANSI-cc systems.)

All of which is mostly orthogonal to the remark that started the whole
thing, namely, that fsresize.c is written in gcc rather than (even
post-ANSI) C.  I don't really see what the problem here is; we have
utilities written in other languages than C in the tree already, some
of which are in languages that aren't widespread, like modern lex, or
gawk, or whichever sh knockoff our sh is).  I don't see what's wrong
with having a (nonessential) utility written in gcc.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu