Re: Spirit rover OS problems ( a reliable language )

From: Dave Hansen (iddw_at_hotmail.com)
Date: 02/16/04 

Date: Mon, 16 Feb 2004 21:28:00 GMT

On Fri, 13 Feb 2004 09:09:21 GMT, "Scott Moore" <samiam@moorecad.com>
wrote:

>
>"Dave Hansen" <iddw@hotmail.com> wrote in message news:402b8f85.86573082@News.CIS.DFN.DE...
[... much snippage ...]
[... Apologies: attributions muddled somewhat ...]
>> Here's an actual example:
>>
>> --- begin included file ---
>> C:\Dave>type vtlint.c
>> void set(int *b)
>> {
>> b[100] = 5;
>> }
>>
>> int array[100];
>>
>> void test()
>> {
>> set(array);
>> }
>>
>> C:\Dave>lint-nt -u -passes(2) vtlint.c
>> PC-lint for C/C++ (NT) Ver. 8.00n, Copyright Gimpel Software 1985-2003
>>
>> --- Module: vtlint.c
>>
>> /// Start of Pass 2 ///
>>
>> --- Module: vtlint.c
>>
>> During Specific Walk:
>> File vtlint.c line 10: set([100])
>> vtlint.c 3 Warning 415: Likely access of out-of-bounds pointer (1
>> beyond end
>> of data) by operator '[' [Reference: file vtlint.c: lines 3, 10]
>> vtlint.c 3 Info 831: Reference cited in prior message
>> vtlint.c 10 Info 831: Reference cited in prior message
>>
>> C:\Dave>
>>
>> --- end included file ---
>>
>> >
>> >Cannot be caught because the compiler has no idea where b came from
>> >or what it points to. There is no underlying model of safety for
>> >lint to use.
>>
>> Impressive, eh? PC-lint does try to find out where b comes from, and
>> is usually quite successful.
>
>No, it cannot find this out all the time. It is not a %100 solution.

Heckuva lot better than "Cannot be caught..."

>Type safe languages are a %100 percent solution.

Excrement of a male bovine. There is no silver bullet.

[...]

>> >What occurs in real life is that you get massive amounts of warnings.
>>
>> Lint early. Lint often. Lint is your *friend*.
>
>Again, all this accomplishes is loads of (possibly irrelivant) warnings

Again, excrement -- well you get the idea. If you lint often, you
learn to avoid constructs lint considers dangerous. If you lint
early, you catch and eliminate the worst problems (which are often
typos) before they become hidden in reams of code and other errors.
You don't ever get "loads of (possibly irrelivant) warnings."

>that if you correct, you might have better code. No matter how good
>it is, it cannot be %100 complete, because the information to do

Again, there is no silver bullet -- or in words you seem to like
better, there is no "100% complete solution."

>that does not exist in the C language. Other languages do not have
>that restriction, and don't need to issue warnings for everything,
>and don't need to use words such as "likely" and "possible" in their
>output. If you have misused an array reference, that is known, its
>an error, not a warning. If you have misused a pointer, that is an
>error, not a warning.

If you have a language which does not allow you to "abuse" pointers
(and other data types) in a useful manner, you have a language that
is, at best, a toy. Toy languages must be extended to be useful. If
you're luck, they extend the same way. Delphi, Turbo, GNU, and
FreePascal all allow typecasts with a syntax similar to C++, e.g.

   charptr := PointerToChar(intptr);

>
>>
>> One (complete, buggy, never-before-linted) project I linted generated
>> an error file three times the size of the source code.
>>
>> >If the code had not ever been compiled with something like
>> >-wall (gcc for "warn all on"), this would be a massive clean up
>> >project which most companies would balk at. This company had been
>> >running -wall tho, and the warnings were considered manageable.
>> >However, there was a multimonth cleanup project that would have to
>> >occur. To give you an idea of it, the tools were complaining that
>> >"printf" returned a value that was ignored. When was the last time
>> >you saw the return value of printf used for anything ?
>>
>> PC-lint has a very flexible means of disabling unnecessary warnings.
>> In the case of this specific example, the default configuration for
>> all the supported compilers includes "-esym(534,printf)" which says
>> "don't report error 534 for the symbol printf."
>>
>
>I don't doubt that your lint program is very impressive to you.

My, what a long nose you have...

I was merely answering one of the most-often-given objections to lint
-- yards and yards of useless warnings

>To me, its a very complex program that is completely unecessary
>in other, type safe, languages.

You go ahead and believe that, if it gives you comfort.

[...]
>> >Why again is C a better idea than a language that had type safety
>> >built in from day one ?
>>
>> C never competed with Pascal or Ada or any other HLL (with or without
>> type safety). C was competing (and in many cases is still competing)
>> with assembly. It's popular because of:
>>
>> 1) Target platform support. The only microprocessor/microcontrollers
>> I can name that don't have a supporting C compiler are 4-bitters.
>
>Every pasture has sh*t laying on it. That does not make same a good
>product.

If you're freezing to death, burning cow pats for heat is a far
superior solution to wishing for a cord of seasoned firewood.

>
>>
>> 2) Serendipity. C was becoming popular just about the time embedded
>> microcontrollers were getting large enough to support HLLs and
>> compiler technology was getting to the point where the generated code
>> was nearly as good as hand-crafted assembly.
>
>This is the same as point (1), ie., "there seem to be more C compilers
>in the world". There is no particular efficiency advantage to C.

No so, it is more an explanation for point (1). Chip and tool vendors
saw C as an "easy" HLL to implement, one which left a great deal of
control with the programmer (to make the auld fartes more
comfortable), but provided some abstraction from the bare wires. It's
still better than raw assembly.

>
>>
>> 3) Perceived efficiency. C is a lower-level HLL. Especially for
>> embedded work, the bitwise operators were a great boon.
>
>"perceived". Well put. The efficiency advantage of C lies between
>the programmers ears.

Let me tell you about my first experience with Pascal on a micro.

I learned programming in Pascal (after one semester of basic BASIC in
High School and one quarter of introductory FORTRAN in College). I
was a _BIG_ fan of the language.

The application was a graphic screen dump for the IBM PC. Winter
1982. Original PC, 64k RAM (Wow!), CGA, using edlin and the two-pass
IBM Pascal compiler (one disk per pass).

TSR. Read the video memory, reformat for the printer binary output
mode, use the BIOS to write to the printer port. It worked well
enough (certainly faster than the printer. But I couldn't get it less
than 25k.

No good.

Re-write in assembly. Less than 2k.

Never tried it in C, But I can tell you the "perceived"
*in*efficiencies of Pascal (pre-turbo) and similar languages were
well-earned.

>
>>
>> 4) Inertia. Most embedded programmers know C. Most embedded jobs
>> involve programming in C. Each feeds of the other. Embedded
>> programmers, as a rule, are a conservative bunch. They stick to what
>> works. They are suspicious of abstraction.
>
>Fortran had this advantage as well. Is fortran popular now ?

Actually yes. So is COBOL. Neither was ever popular for embedded
work, though.

>
>>
>> Summary: I'm not really arguing with you here. My points are 1) Lint
>> is better than you think,
>
>Ive done more work with "super lints" than anyone here, and most likely
>you as well. Dumping lots of "possibles" and "likelys" on the programmer
>is not productive programming, it is programming by paranoia.

You've done more dumping on "super lints" than anyone here, which
leads me to believe you know very little about C, lint, or embedded
programming. When working on embedded systems, paranoia is a *good*
thing.

>
>If the compiler is worth a damm, it can check absolutely if the program
>is right or wrong. C compilers cannot perform this act because the

I take it you've never heard of the halting problem.

>language does not let the compiler do it.
>
>Now notice the subject of this thread. A $800 Million dollar Mars lander
>was sent across space to be felled by a 2 bit software error. C and
>"super lint" have no place in the scope of $800 Million of our
>tax dollars.

Good idea: read the thread. You'll find the Mars lander was "felled"
by an error that had as little to do with C as the error which
"felled" Ariane 5 had to do with Ada. Summary: somebody called a
function with the wrong value for an option parameter. The option
used was legal, but it was wrong. The code could have been written in
assembly, Pascal, Ada, Forth, MODULA-2, Z, or any other irrelevant
language you wish to pull out of you hat. None of them could have
caught the error.

Attributing magic properties to any language is worse than futile.
When the language fails to live up to its billing, the critics come
back and say, "See? You shoulda done it *my* way in the first place."

>
>> 2) without C (or something like it) we (this
>> *is* comp.arch.embedded) would still be mired is assembly. Which is
>> wilder and wester than C. ;-)
>
>Not correct. The language used for most embedded is pure happenstance.

I'm not sure how to respond to this. That's sort of what I've been
saying. Although I would call it serendipity (or "being in the right
place at the right time") rather than "happenstance."

There are good reasons C is as popular as it is. There are good
reasons it shouldn't be. But it is. And it will remain so. And
there's nothing you or I can do to change that. There's too much
intertia.

So what's wrong with trying to make lemonade from the lemons we've
been given?

Lemonade is pretty tasty.

>I don't use C in my embedded work unless the customer requests it.
>It delivers a less reliable product for more work, and it is not
>the appropriate language for any serious work, IMHO.

Prithee tell, what *do* you use, and for what platforms?

>
>It CERTAINLY is not appropriate for life support applications or serious
>money work. In fact, it is probally a worse choice than assembly language,
>which is at least transparent. C removes transparency from the code
>without removing assemblys bug potential, a disasterous combination.

Now you're sounding like one of the auld fartes. Get thee behind me!

Regards,

                               -=Dave 

-- 
Experience is the name everyone gives their mistakes.
                           -Oscar Wilde
A dream of competence, too closely confronted.  iddw@my-deja.com