Re: OT: Language War (Re: "C" Manual)
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, it's not really a string (there's no
such thing in c++ language, there is a string as part of standard
library (runtime?-))
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!
> Therefore, I claim that type safety is a more fundamental concept than
> resource mangement.
well, why?
> > that's all interesting, but the point was that the perl type system is
> > as weak as I can imagine yet it doesn't lead to segfaults... it's the
> > resource allocation!
>
> Type safety != `strong' types. They're orthogonal. (Well, sort of. It
> turns out that `strong types' isn't a very well-defined concept;
> language researchers prefer to discuss compile-time type verification.
> *That* definitely has nothing to do with type safety.)
>
> > If you cannot make sure that MyUserType variable will only be assigned
> > MyUserType values then you have (almost) NO type safety.
>
> That's only meaningful if you can declare a variable to be MyUserType at
> runtime. This does not apply to a whole variety of languages, many of
> which are still type-safe.
>
> (I think I'm just going to decide that Perl's type system is on crack.
pretty much, it's quite strange.
> But what do you expect when a linguist designs a programming language?)
perl?
> > > In any case, memory allocation errors aren't the only cause of
> > > segmentation faults---how about walking off the end of an array? Here,
> > > I claim that Perl *does* maintain type-safety, although in a seriously
> > > fscked-up way: it simply expands the array to make the reference valid.
> >
> > it's not the types! it doesn't care about types at all. it just makes
> > sure you always have a place to store whatever you are about to store.
> > what does that have with types? not much. it has to know what are you
> > trying to store but it doesn't care at all what was there before, what's
> > the type of variable where you are storing it. again, I find it pretty
> > strange to call that kind of behaviour 'type safety'.
>
> Yes, it *is* types. Remember the definition of type-safety:
>
> If an expression E is determined at compile time to have type T,
> then evaluating E will have one of two results:
>
> 1) The value of E is a valid object of type T and not just some
> random collection of bits we're misinterpreting as a T.
perl definitely doesn't satisfy this one, or only in very pervert way.
the objects (any variables, not objects as in OO) can evaluate as
different things (e.g. scalar versus array context), even as nothing,
it's just that perl handles nothing better then C (it doesn't do
anything with nothing, because it knows what's allocated).
the other thing is that often it is not evaluated at compile time...
> 2) a well-defined runtime error occurs (e.g., Java's
> ArrayBoundsException).
or segfault? just kidding...
is java type-safe? http://www.research.att.com/~vj/bug.html
perl often does not give you any error message, it just does something
it consider OK to do...
> There are no other possibilities.
>
> In this particular case, Perl chooses to use the memory allocation
> system to satisfy type safety (it creates a new T, initializes it, and
> returns it). It's not the only possibility, though; Java would throw an
> exception in this case. No allocation involved.
you just wrote there are no other possibilites and then two lines
later you list another possiblity (what perl does).
Perl definitely doesn't guarantee that something will be evaluated as
some particular type. so you might not get random collection of bits (as
in non-allocated piece of memory with random content) but you can get
surprising values anyway (different types). You can evaluate basically
anything as anything in perl, you always get something (that doesn't
segfault but doesn't make sense either).
e.g.
$i = 1;
print "\$i [$i]\n";
print "\@\$i [@$i]\n";
it works, you can evaluate $i as a scalar or as a reference to an
array (it's value is 1 (number one), it's definitely not a valid array
reference but you get no error, just bogus data).
IMO perl is not type-safe language. and proves that you can have
language with automatic resource allocation control, not type-safe that
doesn't have segfault problems like e.g. c has.
what about EiC (C interpreter)?
EiC 13> q = (char*)1000;
Error in ::EiC:: near line 13:
EiC illegal storage access, file ::EiC::, line 12
Error: clean up forced
EiC 14>
is it more type-safe now? IMO it's just guarding acces to memory...
erik
Reply to: