>>> Leaving things as they are results in the least work all around.
>> Sure, except for the fact that the way things are now is _broken_.
> Some parts of the system (e.g. unvis(3)) are broken, yes.  But I
> don't think that means that we should dump the system we have for
> strict ANSI;

Nor - that I recall - has anyone suggested we do so.  What I thought
was being suggested - and I support - is relaxing our style rules to
accept native-ANSI code, instead of requiring that it be uglified with
_P(()) and old-style definitions.

>>> But ANSI/ISO C is a different language.
>> But I would suggest that the majority of our programmers are more
>> comfortable in ANSI C, [...]
> Uh, I'm willing to bet that most of the core NetBSD folks were
> hacking C long before ANSI came along and standardized it.

I was (hacking C long before ANSI, that is), though I'm hardly core.
I'm also presently more comfortable writing in ANSI C than in K&R C.

Having been working with C since before ANSI is not inconsistent with
currently preferring ANSI C over pre-ANSI C.

Indeed, all my new code is written to build cleanly with gcc -Werror -W
-Wall -Wpointer-arith -Wcast-qual -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wno-uninitialized (with a few occasions where I
use -Wno-error when I run into things like the old <sys/signal.h>).
There probably are things a good lint would catch that this doesn't,
but I have trouble thinking of any (except for failure to use return
values, a point on which I agree with rms) - which means they aren't
errors that have given me any significant trouble.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B