> From: Luke Mewburn <lukem@netbsd.org>
>
>
> Module Name:	syssrc
> Committed By:	lukem
> Date:		Mon Feb 26 16:32:48 UTC 2001
>
> Modified Files:
> 	syssrc/sys/sys: proc.h
>
> Log Message:
> convert to ANSI KNF
>:::

This log message was incorrect. The entire proc.h already _was_ ANSI, what
happened here was some KNF and removal of all the __P() macros, and a little
type checking was removed. (Yes!)

It's often unwise to churn the source tree with massive edits for trivial
benefits, and the cost of the churn is apportioned unfairly.  I wish the
temptation to fill up the change logs for reasons as trivial as this was
resisted more often. But cluttering logs and forcing the recompile (very
slow on some ports) is the minor problem.

This change broke the compiles on 23, count'em, 23 ports, unless some
unknown number of them (not alpha) don't count warnings as errors. It also,
contrary to the log message, actually made our type checking slightly
_weaker_, not stronger, as I will explain.

A different change in this sweep broke poll().

Anyway, it turns out that __P() is a more subtle macro than it might seem.
It prevents the macro replacement of the preceding preprocessor token by
what ANSI C calls a "function-like" macro (as opposed to an object-like
macro) definition, and as a result, a function can be defined away in a
null macro yet at the same time its identifier in an ANSI prototype will
not be replaced. (If replaced, you get stuff like "void (struct proc *);".)

Most ports define away cpu_wait(), yet with __P everyone gets a valid
prototype. This is a good thing. Without __P the prototype becomes wacky
and there is No Type Checking unless the ultimate use causes a type error.
Having a prototype exist applies a stronger type check than do most macro
replacements.  This requires __P or some really goofy #ifdef'ing.

I've just checked this behavior against ANSI X3.159-1989 and it seems at
first glance to be clearly correct*, although I agree the ice is getting
a bit thin".

I strongly suggest that we revert this delta and I think we might want to
keep __P(). I certainly agree that we will never want to use __P for its
original purpose of preserving K&R conformance, but now it has a different
raison d'existence: preserving C89 conformance during the current transition
to better things like inline.

	--Ross

*Because rescanning is specified as: replacement text and "subsequent
preprocessing tokens", see 6.8.3.4.                        ^^^^^^^^^^

Also, it clearly specifies that a '(' must follow an identifier "as the
next preprocessing token" for any "instance of the function-like macro
name". See 6.8.3.