Re: OT: Language War (Re: "C" Manual)

[Richard Cobbe <cobbe@airmail.net>]

Lo, on Tuesday, January 1, Ben Collins did write:

> On Tue, Jan 01, 2002 at 10:12:09AM -0600, Richard Cobbe wrote:
> > 
> > > Secondly, you can make this mistake with any language that allows
> > > references (perl, python, and java all allow it). Just replace free()
> > > with some other assignment that changes what a is, and ultimately you
> > > change b, which referenced it, unintentionally.
> > 
> > True.  That, however, is not a type error of the sort that I'm
> > describing.  And, in any case, the behavior of the program in that
> > situation is well-defined by the language specification.  This is *not*
> > the case with C or C++.
> 
> Of course it is defined. It says that after you free() an allocation,
> that the memory the pointer references is gone and using the pointer
> afterwards is undefined.

No, the program's behavior is *NOT* defined.  If it were defined, you
would be able to predict the exact output of the program.  Saying that
the standard specifically marks the program as having undefined behavior
does not count as defining its behavior.

In the alternative that you suggest (some assignment which changes a
rather than deleting it), the program's output *is* predictable.  You're
going to get a string printed out, and this string will appear as a
string literal in the program's source or be constructed by the program
during execution.  The important thing is that it will have been
constructed as a string and not be some random sequence of bytes.
Predicting the exact string that is printed may require some effort, but
(assuming the absence of pseudo-random number generators and assuming
that you know the program's full input) it is possible.

Richard