Re: OT: Language War (Re: "C" Manual)
On Tue, Jan 01, 2002 at 09:44:17PM -0600, Richard Cobbe wrote:
>
> 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.
Every programming language has behaviors that are undefined. Just
because in C it can cause a segfault doesn't mean the other languages
are any better. Show me one language that doesn't have some action that
is classified as undefined.
Documenting that something is undefined is called a specification. It is
there so you know that you cannot rely on certain behavior. If you
ignore that, then no language is going to help you.
--
.----------=======-=-======-=========-----------=====------------=-=-----.
/ Ben Collins -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: