Re: OT: Language War (Re: "C" Manual)
On Thu, Jan 03, 2002 at 09:10:56PM -0800, Erik Steffl wrote:
| Richard Cobbe wrote:
| >
| > Lo, on Thursday, January 3, Erik Steffl did write:
| >
| > > what's the difference? the point is you can assign almost anything to
| > > anything, and yet there is no segfault - i.e. the strength of types has
| > > nothing (sort of) to do with segfaults... the resource allocation is
| > > crucial...
| >
| > Type safety (plus dynamic allocation) implies advanced memory
| > management. The converse is not true: you can slap Boehm's conservative
| > GC onto a C++ program, but you can still get segmentation faults:
| >
| > char str[] = { 'b', 'a', 'd', ' ', 's', 't', 'r', 'i', 'n', 'g' };
| > // note the lack of a terminating '\0'!
| > cout << str;
| >
| > No allocation issues involved. As Ben Collins pointed out elsewhere in
| > this thread (bit of a tree-shaped thread, isn't it?), this won't
| > necessarily cause a segfault, but it can. It's also a violation of
| > type-safety: cout expects a null-terminated string, and as far as the
| > compiler is concerned, str fits this. However, there's no runtime check
| > in the output routine to verify that this is, in fact, the case. Ooops.
|
| that's not really good analysis of what's actually going on. the str
| is actually array of characters,
yes,
| it's not really a string
it is. More formally it is a C-string, as opposed to std::string
| (there's no such thing in c++ language,
Then what is the type of the following expression ?
"hello world"
It is a string. The compiler calls it "const char[11]".
| there is a string as part of standard library (runtime?-))
There are many "types" of string in C++.
| so the problem here is that the actual value of the variable is not
| according the specs for cout, it's of correct type (char *). And str
| certainly evaluates to char *, not a random collection of bits (it's not
| really a char * but it doesn't matter in this case)
|
| I don't see any type related problem here. cout assumes something
| about the value, it's not true, BOOM!
In C/C++ there is an invariant on strings ("char*", which is
essentially equivalent to "char[]") that they end with a NUL byte.
The invariant is an implicit precondition for the operation that was
performed. The coder above broke that invariant, which means that the
precondition for the operation wasn't met, and the result is
"undefined" (a segfault, if you're lucky).
A better approach is to use classes with set interfaces to ensure that
any invariants on the type can't be broken, but C doesn't have such
capabilities. It is also better if the system can perform those
checks for you, but it isn't always possible or feasible.
Eiffel provides a way for you to specify the invariants,
preconditions, and postconditions of portions of code (classes and
methods); but even so, not everything can be checked.
| > Therefore, I claim that type safety is a more fundamental concept than
| > resource mangement.
|
| well, why?
See the above discussion of invariants, preconditions, and
postconditions. Those are part of a "type", but have little to do
with resource management.
| is java type-safe? http://www.research.att.com/~vj/bug.html
Interesting. (I've only just read the abstract)
-D
--
Pleasant words are a honeycomb,
sweet to the soul and healing to the bones.
Proverbs 16:24
Reply to: