>I'd like to add a couple things to this rather worn-out argument.

>1) I think it's unreasonable to assume that anyone who has an interest in 
>starting a port also has an interest in porting gcc.  In the overwhelming 
>majority of cases, I'm sure this is not true.

Yes, but in how many cases does gcc need to be ported?  The build is
trivial, although 2.7.2 requires the user to delete a (correct) declaration
of free in at least one source file.

>2) The amount of work required to make such sweeping changes, while 
>finite, is tremendously large.  Not difficult, just tedious -- even with 
>the help of tools.

I don't advocate trying to make the change in existing source; I advocate
deprecating the old style.  Does any system utility still use gets? :)
We can use the new style, and convert as we go.  The same thing will happen
when C9X answers the integer size question, in all probability - it'll
take ages to sort out, but once there's a "correct" solution, we may want
to start migrating.

>I think (1) is far more important than (2).  Further, it's folly to 
>assert that any machine capable of running NetBSD will have a port of 
>gcc available, especially with new hardware.  It took quite some time for 
>useful PA-RISC gcc/gas source were available, for example...

Yes, but when they weren't, how would anyone have meaningfully gotten netbsd
running?  With or without HP's ANSI compiler, NetBSD would have needed to
have binary support for HP-UX/PA-RISC binaries *before* it could have gotten
far enough to be interesting.

About all you can do without a reliable compiler in source form for your
target chip is play around with kernel stuff.  You can't make a live
system sanely.  It might be possible, but I'd guess it'd be at least an
order of magnitude easier to get a naive gcc running.  You don't need
perfect optimizations, just enough machine description to build everything.

-s