[Info-vax] Memory Safe Programming Languages

[Dan Cross]

In article <l50m6uF7ocvU3 at mid.individual.net>,
bill  <bill.gunshannon at gmail.com> wrote:
>[snip]
>But, explanation 2 still stands.  If the "safe" code written in
>Ada can be converted to C then, obviously, the same "safe" code
>could be written directly using C.  The question really is why do
>programmers choose  not to.

Not really.  The generated "safe" code need not be as safe as
the original source Ada.  For example, if this Ada compiler that
generates C does array bounds checking, and can statically
verify that an array access is within bounds, it need not
insert that check in the generated C code.  Similarly with all
sorts of things; verifying alignment, weird type casts, etc.
The Ada compiler can generate spaghetti C that is unreadable to
a human and it doesn't matter, because it's just an intermediate
representation.

>> OTOH, it could sound like the reasoning of someone trying to desperately
>> claim that C is somehow as safe as Ada. :-)
>
>It is.  It is not any shortcoming in the language that makes C
>"unsafe".  It is the practices of the programmers.

This is reductio ad absurdum.  There's a lot in the language not
to be liked.  Quick, is the following always well-defined?

uint16_t
mul(uint16_t a, uint16_t b)
{
	return a * b;
}

It's super easy to trivially fall over UB in C.

>> Also, how long did this GNAT compiler that translated into C
>> actually exist for ? Was it something that once existed for a couple
>> of years about 30-35 years ago and was never used again.
>
>Really don't remember.  That was more than a lifetime ago in
>computer years.  :-)
>
>> 
>> I first started really using Ada compilers around the gcc 2.8 timeframe
>> (IIRC) and have never encountered this Ada to C translator you speak of.
>
>A lot of the early Gnu compilers started as translations to C
>and compilation with GCC.  P2C, F2C  As has been stated many times,
>C is really just a slightly higher level than assembler.
>You know, one can easily write buffer overflows, out of bounds arrays,
>type mismatches, etc. with assembler but no one blames the assembler
>for it.

Sure they do.  There's a reason that, these days, assembler is
mostly a _target_ and not a source language.  There are
exceptions of course, but these usually fall into the domain of
either legacy code (z/Arch assembler, MACRO-32) or specialized
use (e.g., the supervisor instruction set in an OS).  Most
programs these days are written in higher level languages
because we know that a) programming in assembler is often
tedious and b) it is error-prone.

	- Dan C.