Re: "C" vrs ADA

[chuck@amdahl.amdahl.com (Charles Simmons)]

In article <6338@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>The language the code is written in is really a very small part of
>structured software methodology; one can apply the techniques in
>COBOL, PL/I, FORTRAN, Pascal, or C.  As a matter of fact, there are
>C environments for sale that are just about as "safe" as Ada; most
>typo and similar errors are caught by C compilation and "lint";
>unhandled exceptions in C typically produce an immediate core image
>for debugging, etc.  Very little difference, really.

Um...  How do these C environments detect subscript range errors
in a piece of code like:

        strcpy(s,t)
        char *s, *t;
        { while (*s++ = *t++); return s;}

Although an unhandled exception in C "typically" produces a dump,
it does not "always" produce a dump.  Also, the dump may occur long
after the invalid code was executed, making it more difficult to figure
out what went wrong.

Yes, lint does work quite well.  Unfortunately, I come from a PL1
background where the compiler generated type-checking information
and the linker made sure everything matched.  With lint, I have to
have to perform an extra pass through my code.  Admittedly, it's not
a whole lot of work, but if type-checking were integrated with the
compiler, things would move along a little faster...

>C's one really major problem from the structured viewpoint is
>that it has only two effective levels of name space, module
>internal and global.  This makes it necessary to strictly
>allocate global names, which is an annoying but solvable problem.

Tee hee...  And here I was beginning to think the name space rules
were one of the advantages of C.  Actually, arn't there three levels
of name space?  "static global" or a variable that can only be seen
from within a file, "procedure internal" or a variable that can only
be seen from within the surrounding procedure (or "begin end" block),
and "external global" or a variable that exists everywhere.

-- Chuck