[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



dman wrote:
> 
> 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

  no, it is not a string as there is no such type in C language. it is
used as string in many functions. but it is not a string, it is an array
of characters.

  the C-string is '\0'-terminated array of characters but that's NOT a C
type.

> | (there's no such thing in c++ language,
> 
> Then what is the type of the following expression ?
> 
>     "hello world"

  it is an array of characters. const (both it's address and value).

> It is a string.  The compiler calls it "const char[11]".

  it is what compiler calls it, it's not a string.

> | there is a string as part of standard library (runtime?-))
> 
> There are many "types" of string in C++.

  ? in C++ language there are no strings. in C++ standard libraries
there is a string class (template). you can, of course, define your own
string types 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.

  no, that's not true.

  char* or char[] are arrays. SOME functions use them in a way that
requires '\0' character to be somewhere within allocated space for given
array. but that's strictly requirement of value for some pecific
functions, it has nothing to do with definition of language.

  it is perfectly legal to use character arrays that have no '\0'
character (just don't use them in functions that assume the '\0' to be
last character to use).

> 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).

  yes, but that's what was said before. it doesn't have anything to do
with types, it is simply bad value. just like you cannot divide by zero.

> 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.

  that's all good, but the point here is that it's not type issue. the
type of variable and the domain of valid values are two separate issues
(well, you could define a new type where type would be the same as valid
domain but it's not always possible).

> | > 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.

  above discussion is irrelevant to the issue at hand, there is no such
type in C and the preconditions are only for specific functions (and are
more part of specifying valid domain that valid types).

  if you don't believe it, just check it again - there is no type error
in the C code quoted above. it's the value that's wrong for given
function (operator <<).

	erik



Reply to: