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 \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'