Re: OT: Language War (Re: "C" Manual)
On Thu, 03 Jan 2002 17:34:00 -0600 (CST), 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.
Neophyte that I am, I feel like I'm bringing a knife to this gunfight.
This example looks to be a cheat, in that you've defined an array and
then treated it as a string (legal). Had you defined a string, it would
be null terminated and index addressable. In any normal array operation
wouldn't you be checking for array limits? The fact that you *can*
screw up doesn't mean you have to. This strikes me as falling under the
heading of programmer or logic error, just as is freeing the pointer
that another pointer points to. If you are nesting pointers, don't you
create a means to track dependencies? In a relatively low-level
language like c/c++, isn't the programmer responsible for code
integrity?
>
>Therefore, I claim that type safety is a more fundamental concept than
>resource mangement.
>
Is there a difference? Again, my ignorance knowing no bounds. Doesn't
the type define the required allocation? And if typing is loose or
undefined doesn't allocation depend on ad hoc testing? In the example
above, is it a type, or allocation error if the *programmer* decides to
access str[10]? (If I counted right, that's the next byte after the
array bloc.)
This discussion has merit, not from the religious aspect of angels
dancing on pinheads, but rather will the pin hold my note on the cork
board?
gt
Yes I fear I am living beyond my mental means--Nash
Reply to: