> > I don't quite understand why we need pre-ANSI C for bootstrapping
>
> The current kernel code is _not_ pre ANSI.  It simply uses old-style
> function definitions - quite legit.

By "pre-ANSI C", I meant "code that is acceptable to a pre-ANSI C
compiler".  I did not mean "code that is not acceptable to an ANSI C
compiler".

> > the source tree, I would prefer to see a scheme using something like
> > "unproto", rather than the present system of using __P() macros and
> > stuff.
>
> What does anyone think it is costing - using the old style
> definitions?  Why change something that is not broken?

A benefit of prototypes is better compile-time checking.  A cost of
using tricks like __P() macros is in reduced legibility of the source.
If there's a need to compile the code with a pre-ANSI compiler (and
it's not clear to me that there is such a need), then that need could
probably be met with unproto instead of with __P().  In either case,
some care will be needed in writing the code to ensure that it will
work with both old and new compilers, but the code written for use with
unproto can be more legible and a lot closer to code written purely for
new compilers than the code that uses __P() or similar macros would be.

There are a range of options available.  Here are some of them:

  1. Write code for ANSI C compilers, using prototypes and other new
     features.  Ignore pre-ANSI compilers entirely.

  2. Write code for ANSI C compilers, using prototypes and other new
     features.  Avoid using constructs that can't be translated by
     "unproto" into a form that is acceptable to pre-ANSI compilers.

  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.

  4. Write code that is directly acceptable to both old and new
     compilers, without trying tu use prototypes or other new features
     in any way.

The present strategy in NetBSD seems to be something like option
3 above.  I argue that option 2 above should provide sufficient
accommodation for old compilers (if there's any need at all to
accommodate old compilers), while freeing the code of the __P() macros
that many folk think are ugly.

--apb (Alan Barrett)