On Wed, 4 Jun 1997, Mike Long wrote:

> 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; it's a lot less work just to fix the bugs in our existing
> system.

It's not clear that there _is_ a good solution to the character argument
passing problem -- are you suggesting that changing every function which
takes a char to take some other data type will be _less_ intrusive?

> Uh, I'm willing to bet that most of the core NetBSD folks were
> hacking C long before ANSI came along and standardized it.

Obviously.  But I would suggest that most have since moved to ANSI C for
most purposes, and many are writing ANSI C and backporting it to our
conventions....

> Not submitting code because of a lack of time to shoehorn it into our
> guidelines is not an excuse, IMHO.  Just submit the thing as-is and
> whoever wants to use it can KNFify it.

Sure, but I'm more concerned about the reliability problems caused in
the code that _is_ being backported.  Code which depends on ANSI C
argument passing and other conventions (and often gcc or local
extensions), but has been tweaked so that errors which would have
occurred at compile time under K&R C will now occur at run time.

All of this would be worth pursuing if there was any clear benefit from
keeping K&R compatibility.  As no one has pointed to _any_ system with a
K&R compiler and no ANSI compiler, and since I find it hard to believe
any new platform will ship without ANSI C, it is by no means clear to me
that there is any benefit from this sort of hack.

--
				Jim Wise
				jim.wise@turner.com