The C language in the planet Mars

J

jacob navia

Mankind has now two robots wandering about in the planet Mars. No,
it wasn't Mars that invaded Earth, but Earth that landed in Mars
more than two years ago.

After some initial OS glitches (Chris Torek can comment
on those probably) in the Spirit robot, software has done
smoothly ever since.

All the software is written in C, what is a good decision
but also a bad one, C with its warts and all...

In the last two weeks, a software upgrade was sent from
earth to Mars, and the upgrade is scheduled to be
tested this days. Software upgrades take a lot of time
when they are done with several million kilometers
distance!

The Mars Exploration Rover software (MER) is around
650 000 lines of C. The Ames research center developed a
static tester for the software [2] and in 30 minutes
it discovered...

o Un-initialized variable usage
o Returning the address of a local variable (!!!!)
o Overflow in constant expression.

I wonder what kind of compilers does the VXWorks system
use, but almost all compilers I know of will try to
diagnose this kind of errors...

In a news item published in Space daily [1], Green Hills software
boasted that
< quote >
"Green Hills Software Tools Critical To Mars Rover Missions"

Both the "Opportunity" rover, launched July 7, and the "Spirit" rover,
launched June 10, are being directed and controlled by software programs
and systems written with the use of Green Hills development tools.

< end quote >

Green Hills doesn't emit a diagnostic for returning the address of
a local variable?


References:
[1]
http://www.marsdaily.com/reports/Green_Hills_Software_Tools_Critical_To_Mars_Rover_Missions.html
[2]
http://ic.arc.nasa.gov/researchinfusion/materials/CGS/SMC-IT03.pdf
 
R

Richard Tobin

jacob navia said:
o Returning the address of a local variable (!!!!)
Green Hills doesn't emit a diagnostic for returning the address of
a local variable?

I don't know the details of this particular case, but suppose the
code was something like this:

int *foo(void)
{
int local;
int *pointer;

pointer = &local;

return pointer;
}

How many compilers produce a warning for that?

-- Richard
 
J

jacob navia

Richard Tobin a écrit :
I don't know the details of this particular case, but suppose the
code was something like this:

int *foo(void)
{
int local;
int *pointer;

pointer = &local;

return pointer;
}

How many compilers produce a warning for that?

-- Richard

Yes, you are right. That would be much more
difficult to find. The other errors are maybe
easier: const overflow can be detected at
compile time.
 
N

Nils Weller

Richard Tobin a écrit :

Yes, you are right. That would be much more
difficult to find.

Hmm, maybe it would be feasible to make this a runtime error. With a
typical stack frame layout, the compiler can easily check whether
returned (non-null) pointer values point into the frame, and if that's
the case terminate the process or call a user-defined error handler or
somesuch.

Probably not worth the cost in general, but could come in handy during
development/debugging.
 
S

spibou

Richard said:
I don't know the details of this particular case, but suppose the
code was something like this:

int *foo(void)
{
int local;
int *pointer;

pointer = &local;

return pointer;
}

How many compilers produce a warning for that?

I decided to do a little experiment with the programme below.

int *foo(void)
{
int local;
int *pointer;

pointer = &local;

return pointer;

}

int main() {

return 0 ;
}

The Sun compiler , lint on Solaris and gcc -Wall did not
produce any warnings. But splint gave

o.c:8:12: Stack-allocated storage pointer reachable from return value:
pointer
A stack reference is pointed to by an external reference when the
function
returns. The stack-allocated storage is destroyed after the call,
leaving a
dangling reference. (Use -stackref to inhibit warning)


Spiros Bousbouras
 
B

BubbaGump

Mankind has now two robots wandering about in the planet Mars. No,
it wasn't Mars that invaded Earth, but Earth that landed in Mars
more than two years ago.

After some initial OS glitches (Chris Torek can comment
on those probably) in the Spirit robot, software has done
smoothly ever since.

All the software is written in C, what is a good decision
but also a bad one, C with its warts and all...

Maybe the problem's with the people writing the language as much as it
is with the language itself. French isn't a bad language just because
monkey's can't speak it.

C is good for anal retentive people who catch most of their own
mistakes. It's apparently not good for normal people.
 
R

Richard Heathfield

BubbaGump said:

C is good for anal retentive people who catch most of their own
mistakes.

Are you a qualified psychiatrist, using that term in its medical sense? If
so, please provide evidence to support this.

Or are you just an irksome little jerk who is trying to offend people?
It's apparently not good for normal people.

C is fine for normal people who know how to think. If you don't know how to
think, stay away not just from C, but from programming.
 
H

Ham

int *foo(void)
{
int local;
int *pointer;

pointer = &local;

return pointer;

}

int main() {

return 0 ;
}

PC-LINT produces the following warning for that piece of code:

diy.c 11 Warning 674: Returning address of auto through
variable 'pointer'.

This example is also a sample violation of MISRA C:2004
 
T

Tak-Shing Chan

BubbaGump said:
C [...]
It's apparently not good for normal people.
C is fine for normal people who know how to think.

There are compelling claims that programmers are not normal people ;-)

Indeed. A week or so ago, someone on comp.lang.c wrote,
``Neither is anyone. Normality is a myth. (Do the math. How many
people are normal in every respect?)'' (attribution withheld).

Tak-Shing
 
R

Richard Heathfield

Tak-Shing Chan said:
BubbaGump said:
It's apparently not good for normal people.
C is fine for normal people who know how to think.

There are compelling claims that programmers are not normal people ;-)

Indeed. A week or so ago, someone on comp.lang.c wrote,
``Neither is anyone. Normality is a myth. (Do the math. How many
people are normal in every respect?)'' (attribution withheld).

Touche'. But to quote Emerson, "a foolish consistency is the hobgoblin of
small minds".
 
K

Keith Thompson

Richard Heathfield said:
Touche'. But to quote Emerson, "a foolish consistency is the hobgoblin of
small minds".

Little minds, not small minds. (Like mine, apparently.)
 
K

Karthikeyan D

I decided to do a little experiment with the programme below.

int *foo(void)
{
int local;
int *pointer;

pointer = &local;

return pointer;

}

int main() {

return 0 ;
}

The Sun compiler , lint on Solaris and gcc -Wall did not
produce any warnings.

On Solaris, running lint with the option -Nlevel=2 gives the following
message for the above program

return of a pointer to local variable
local defined at aaa.c(3) :: aaa.c(8)

Thanks

Karthik
 
W

websnarf

Richard said:
BubbaGump said:

C is fine for normal people who know how to think.

And who are willing to expend an unbounded amount of energy to keep
yourself from cutting your fingers off.
[...] If you don't know how to
think, stay away not just from C, but from programming.

But this is a response to your own generated statement, not his
original thesis.

BG is probably like most people, who have decided they just don't have
the energy to deal with juggling ignited razor blades just to deal with
trivial things like abstract data types. Or maybe he's just sick of
the fact that no matter how good you are you cannot sustain writing
perfect, or even near perfect code in C in single large projects
without similarly large (and often on-going) costs.
 
S

spibou

Karthikeyan said:
On Solaris, running lint with the option -Nlevel=2 gives the following
message for the above program

return of a pointer to local variable
local defined at aaa.c(3) :: aaa.c(8)

I had never read the lint man page but I could have never
imagined that a warning tool does not as a default run with
the highest level of warnings. Utterly incomprehensible
design choice.

Thanks for opening my eyes. lint has now been aliased as
lint -Ncheck=%all -Nlevel=4

Spiros Bousbouras
 
K

Keith Thompson

goose said:
See? Its things like that which identifies
the C programmer in everyday conversation :)

Its --> It's
identify --> identifies

(Ok, ok, I'll stop now.)
 
E

Eric Sosman

Keith said:
goose said:
Keith said:
[...]

Touche'. But to quote Emerson, "a foolish consistency is the hobgoblin of
small minds".

Little minds, not small minds. (Like mine, apparently.)

See? Its things like that which identifies
the C programmer in everyday conversation :)


Its --> It's
identify --> identifies

(Ok, ok, I'll stop now.)

that -> which ...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top