Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!lll-lcc!lll-tis!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.lang.c
Subject: Re: Query: Implementation with non-zero NULL
Message-ID: <20402@sun.uucp>
Date: Thu, 4-Jun-87 20:17:30 EDT
Article-I.D.: sun.20402
Posted: Thu Jun  4 20:17:30 1987
Date-Received: Sat, 6-Jun-87 11:21:04 EDT
References: <158@delftcc.UUCP> <1070@viper.Lynx.MN.ORG> <6873@mimsy.UUCP> <1082@viper.Lynx.MN.ORG>
Sender: news@sun.uucp
Lines: 47
Keywords: C, NULL, portability

> With all due respect to Chris and K&R, what I was (poorly) trying to
> say was, that when trying to write portable code, you should never use
> a variable before it's been explicitly initialized.

That depends on what you mean by "portable".  Some people may have to
worry about porting to incorrect C implementations, others don't.  I
refuse to worry about it; if I encounter such an implementation, I
will:

	first, report the bug and determine how soon it can be fixed;

	second, if the bug can't be fixed in a timely fashion, or if
	the vendor is under the delusion that it's a feature, try to
	get some other compiler;

	third, only if all those fail, throw in a crock to get around
	the bug.

If you can't rely on static variables not explicitly initialized
being initialized to zero, what *can* you depend on?  Shall we be
careful about using the "*" operator because somebody's C compiler
might generate code to add 43 and, if the result is negative, rewind
the printer?  How common *are* implementations that don't handle
initializations properly?  How broken are those implementations in
other fashions?

>   What's that you say?  No program would ever fail to run on your
> system because someone used a "feature" defined in K&R that didn't 
> work that way on your system?  Mind telling me what you've been 
> smoking and where I can get some?  :-)  :-)  :-)

Remove the quotation marks around "feature".  Any C implementor who
wants to be taken seriously does not have the option of treating
specifications in K&R as quote "features" unquote and ignoring them.
They can *extend* things (for example, K&R doesn't mention things
like "unsigned long", and doesn't indicate that structure member
names need not be globally unique, but most C implementations these
days support "unsigned long" and non-globally-unique member names),
but not change things in ways that *break* existing code.

At some point, one hopes, the same will be true of the specifications
in the ANSI C spec, and there will be a validation suite to ensure
that the implementor *doesn't* screw up.  Art may be anything you can
get away with, but C isn't.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com