> Hmmm?  I don't get what you're proposing.  All of the NetBSD kernel
> and utilities should already be written in Standard C.  We do still
> use the old function definition syntax, but that's still allowed by
> the Standard.  It also makes it posible for us to port to systems
> where there isn't a gcc port and the only available compiler is K&R.

I believe that this is an important point not to cut ourselves off from
porting other future machines that only have K&R. I also wonder what those
machines are, and since we use gcc why just poping in the -traditional flag
or cross compiling wouldn't work? The machine we port to would also eventually
have to have gcc ported to it anyway if it didn't already have it. If it
did have gcc then why couldn't it just compile as ANSI anyway?? This really
is a question and I am not trying to be a wise ass about it

Couldn't we come to a compromise? What's the reason for wanting to use
ANSI C anyway? Maybe to catch a few prototype mismatch bugs?
Could we extend the concepts already started by the __P() macro in
<sys/cdefs.h> and apply them to kernel functions and libraries?
I am sure you have all seen code such as :

char *
#ifdef USE_PROTOTYPES
strcpy(char *s1, const char *s2);
#else
strcpy(s1,s2)
char *s1;
char *s2;
#endif
{
/* Function code would go here */
}	  

Also const would be
#define const 

There are many holes in this approach, and I welcome reactions ;),
and it creates a little more maintance overhead, however if even one
architecture were able to compile
their kernel or libraries using STANDARD C (i.e. ANSI C) then ALL the 
architectures would benefit in by the commonly shared code being more of
a known consistent state.

So there are two questions:

1) If the machine we are porting to would need to have gcc support eventually
   anyway since we use it in NetBSD, then it probably will be supported under
   it's other OS anyway, so why couldn't it compile ANSI? 

2) Give we must use K&R C because I don't understand  why the answer to
   question #1 isn't it would have a gcc compiler, then: 
   Couldn't we compromise
   and "have our cake and eat it too" by having conditional function 
   implementations? 



-- 
Robert Leland leland@freetocreate.org               436 N. Monroe Street
+1-202-944-5325       (USA Work)                    Arlington, VA 22201-1738
+1-703-525-(7026/3580)(USA Home Fax/Voice)          USA