> > What does anyone think it is costing - using the old style
> > definitions?  Why change something that is not broken?

John Kohl asked:

>Simon> What does anyone think it is costing - using the old style
>Simon> definitions?  Why change something that is not broken?

>Precisely.  When importing new code into the system (be it user-level or
>kernel level), why change new-style function definitions to old ones,
>particularly in cases where there are no narrow types that might cause
>confusion?

All large software projects try to impose a coding style.  This is
very important for overall legibility of code and ultimate
maintainability.  The bulk of NetBSD is old style definitions and
NetBSD promulgates a style guide that says that old style definitions
should be used.  

Thus they are perhaps within their rights to reject code that uses new
style definitons or to change them to match the desired style -
especially if the code is going into the kernel.

And Alan Barrett says:

> A benefit of prototypes is better compile-time checking.  A cost of

Please don't confuse use of prototypes and function definition style.
They are separate issues, and macros like __P() allow you to have the
best of both worlds.

> using tricks like __P() macros is in reduced legibility of the source.

I've never noticed.  On large projects I've always had makefiles setup
to use cproto etc to automagically update prototypes in headers.  
Again, consistent use of a given style etc aids automagic processing.

> There are a range of options available.  Here are some of them:
> 
>   3. Use __P() and similar tricks to write code that is acceptable
>      to both old and new compilers, and that gets the benefit of
>      compile-time prototype checking under new compilers.

That's the winner - as there are no losers.
All the other options have down sides.

--sjg