Re: non-native MAKEDEV [was: Re: CVS commit: basesrc]

[Ross Harvey <ross%teraflop.com@localhost>]

> From: Michael Graff <explorer%flame.org@localhost>
>
> Simon Burge <simonb%netbsd.org@localhost> writes:
>
> > I used MAKEDEV on Ultrix a few weeks ago to make a NFS client for a
> > DECstation 5100.  So, "yes"...
>
> Good enough for me.  :)
>
> > > This is somewhat akin to the "don't use gcc features that will break
> > > Ultrix based compiles" but at least has less silliness :)
> > 
> > Aawwh, what's wrong with Ultrix?  :-)
>
> I don't have a grudge against Ultrix (or users of it :) but I do think
> it is silly to keep gcc-isms out of our source tree just because some
> other compiler doesn't support it.  A prime example is that the style
> guide still requires the old K&R syntax for function declarations, and
> we do that disgusting macro to hide function prototypes in our header
> files.
>
> IMHO, if you're going to port NetBSD to another CPU type, the first
> thing you'd do is want a cross-compiling gcc anyway.
>
> This is a can of worms, btw.  I just like to open it once in a while.
> :)
>
> --Michael


A "prime example"?! It looks to me like you have confused an ANSI vs K&R
issue with a gcc vs language-standards issue.

They are unrelated.

Also, I can think of *lots* of reasons to stick with C standards and
limit dependence on non-standard features of a particular compiler.
We or a user might want to use one of many commercial compilers, some of
which do much better optimization and have much better debuggers than
gcc does. For some platforms, there _is_ no gcc, only commercial
compilers.

Furthermore, the non-standard features are occasionally withdrawn or
substantially changed. Gcc cannot, however, change the standard features.
Furthermore, the standard features are widely documented, and frequently
with careful precision.  These are reasons to use only them.

I'm surprised that I even need to point this out.

        ross.harvey%computer.org@localhost