Subject: Re: Style guide
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 06/04/1997 16:45:06
>>> 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.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B