1. Home
  2. Embedded Programming
  3. Spirit rover OS problems
  4. Page 9

Spirit rover OS problems

I won't comment on that either. :)

That, and maybe the fear that C compilers of the time might choke (or produce unreliable code) if the return statement was buried within a couple of control structures, with local variables and/or setjmp()'s thrown in for fun. :)

More probably that came from mixing up structured programming and functional programming, which does not even have the concept of a "return" or "break" statement.

Then again, some of them might have knee-jerked out of school knowledge, and some might really know what positive and negative effects small routines might have, and *then* have decided against.

I tend to believe that if the "return" statement is allowed any number of times, it is because the C language designers knew what it could be used for. :)

In my experience, no rule is absolute--a bit like in music. You have to know the rules *and why they exist*, and then you decide which ones to follow and which ones to break.

Or, when your program hits a wall, you think about which rule you might have overlooked. :)

For instance, there is a rule about using goto statement, which goes: "don't". :) However, the real rule is: "don't use too many gotos because code flow will become too complex to master". Far too often, people forget either or both of the "too many" and "because" parts.

Once the programmer gets the whole picture, (s)he might decide that in specific cases, a well-designed set of goto statements will break one rule but satisfy many others. Simplicity, to begin with.

I remember a case of complexity measurement where a single function was tagged as awfully more complex (about fifteen times) from the measurement tool's point of view than the rest of the code.

Well, the function merely was a big switch statement with lots of cases, because it was a state machine, and I wanted future readers to rapidly understand and be able to easily modify the code.

But the complexity measurement says "the more cases in a switch, the more complex the code is". It does not matter whether all these cases are similar or completely different.

I could have rewritten it to a pure combinatory use of big tables full of cryptic values, and that would have lowered the complexity measurement...

*and* gone againts the rule itself :), as understanding the tables would have been harder and modifying them would have been a nightmare.

Albert.

Reply to
Albert ARIBAUD
Loading thread data ...

Which is why I used it for my original example, long since snipped, and which was:

Notice that any "single return" desire can easily be satisfied by replacing "return xxx" by "result = xxx" and a final "return result" after the last else clause. With such an auxiliary variable it can also be written as:

result = errnomem; if (!(p = malloc(sizeof *p)) && !(p->cp = malloc(strlen(s) + 1)) free(p); else { /* all fields allocated */ strcpy(p->cp, s); dowhatever(); result = noerr; } return result;

which still points out my theme of the usefulness and clarity of embedded assignments. It relies on the fact that free(NULL) is legal and does nothing, which may not be true for some non-standards-conforming systems.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
Reply to
CBFalconer

Oh, I dunno - there's always a way, even if it ain't real pretty. Just test at the end of the loop instead of at the beginning:

key = EXIT_KEY ; do { if ( key != EXIT_KEY ) process( key) ; key = get_key() ; } while ( key != EXIT_KEY ) ;

It duplicates the test, of course. I still much prefer testing the rvalue of the assignment, but I'd like to modify the line to read:

while ( (key = get_key()) != EXIT_KEY ) /*** TESTING RVALUE ***/

Alternatively, the better C/C++ compilers will normally give a warning for "suspicious" constructs, but allow you to selectively disable particular warnings either globally, or within regions of source. e.g.:

#pragma warning -W1234 turn off warning for deliberate rvalue test while ( (key = get_key()) != EXIT_KEY ) process(key); #pragma warning +W1234

Personally, I think that's ugly, but any methods like these will serve to draw a subsequent reviewer's attention to the fact that something mildly unusual is going on, quite intentionally. That's really more to the point here, in my view.

--
  Max
Reply to
Max

People here seem to be confusing negative reinforcement with punishment. They aren't the same thing. Reinforcement (either positive or negative) increases the frequency of preceding behavior. Punishment decreases the frequency of preceding behavior.

And both are different than punishment.

--
Grant Edwards                   grante             Yow!  I HIJACKED a 747 to
                                  at               get here!! I hope those
                               visi.com            fabulous CONEHEADS are
                                                   at HOME!!
Reply to
Grant Edwards

That's punishment not negative reinforcement.

--
Grant Edwards                   grante             Yow!  I have no actual
                                  at               hairline...
                               visi.com
Reply to
Grant Edwards

Twaddle. Please point to a compiler that will accept:

for (;;) { a = val * 10 /* not a statement - just an expression */ }

Perhaps you would like to look at the productions for "statement" at (in BNF):

formatting link
or look in the back of K&R or the ANSI/ISO standard. An expression is not a statement. A left-most expression followed by a semi-colon DOES reduce to a statement.

Three. Plus two C++, one BCPL, Pascal, ADA, and a couple of "midnight specials". I'm currently writing a portable C# v2 compiler as a background activity (because I like the idea of type-safe genericity).

Compiler writing was a regular part of how I earned my crust for seven years or so in my earlier career. It isn't hard, particularly if you use YACC/LEX or similar tools. Second-year CS students write simple C compilers for term projects. Global data-flow analysis and code optimisation are the only really tricky bits in a C compiler.

Why, anyway? Is this some sort of "who's got the biggest conker" debate?

--
  Max
Reply to
Max

Actually, a lot of the rules of structured programming came from the process of trying to "prove" a program to be correct. Any program can be constructed using only the structured programming constructs (basically no gotos or multiple returns, only if else then and loops). At the time it was thought that this made it possible to analyze the program formally and so possibly allow programs to be proven to be correct. In addition it allowed programs to be more easily read and understood and debugged.

What is actually best is certainly up for debate... that is why we are debating, no?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

Of course they do, but I hope that's not all they teach. Skinner was not the first psychologist with a theory, and certainly not the last, or latest.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net
Reply to
Alan Balmer

Yep, I forgot to mention that alternative (duplicating the test). Here's another example:

do{ key = get_key(); if (key != EXIT_KEY) process(key); } while (key != EXIT_KEY);

Someone else mentioned duplicating the test within the process function, which is probably good defensive programming anyway:

do { key = get_key(); process(key); } while (key != EXIT_KEY);

and a small modification to process so it returns FALSE if key==EXIT_KEY:

while (process(get_key())) continue;

but perhaps that's getting too far from the original example...

In my code, I'd probably just let it go without the comment because of the explicit test. Without the explicit test, it would be something like

while (key = get_key()) /*lint !e720 test of assignment */

to suppress the lint message and signal to the reader that something strange is going on. (Though in this particular case, I'd likely keep the explicit test -- the only implicit tests in my code tend to be for booleans and pointers)

One of the reasons I like PC-lint. The "!e720" comment in my example says "don't report error 720 on this line." (The "test of assignment" is just a comment like any other). The disable/enable form is also available (-e720, +e720), as well as save and change state/ restore state (-save -e720, -restore)

I agree. One of the best uses of lint is to reduce the amount of time required to do a good code review. A module doesn't go to review unless it lints clean. A lint comment is a warning to the reviewer that something strange is going on: pay close attention!

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

The language lawyers can verify, but isn't "assignment expression" the correct answer? This is what allows "if (f = fopen(...))..." to be a valid statement in C.

Reply to
Everett M. Greene

Not particularly more correct than Grant's answer. They're both correct, because:

expression ::= assignment_expression | expression, assignment_expression

No. The condition in the if is indeed an "expression", not an assign-expression. The difference is that

if (a = b, f = fopen(...)) e = f;

is allowed, too. And that is *not* an assignment expression.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

That reminds me of a reason why it is not good practice to put too much stuff (like function calls with side effects) into a test expression.

do{ if ((key = get_key()) != EXIT_KEY) process(key); } while ((key = get_key()) != EXIT_KEY);

Of course you wouldn't necessarily make this error, but it illustrates the issue. By keeping the assignment separate from the test, it is much easier to identify the expression with a side effect.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

What's the question?

Sure. "=" is basically just another binary operator, so

a = 5

and

a == 5

can be used anywhere the language calls for an "expression".

--
Grant Edwards                   grante             Yow!  RELATIVES!!
                                  at               
                               visi.com
Reply to
Grant Edwards

He is right only in part and then only in simplistic terms. Engineering is a much more complex behaviour scenario.

When you have a language that prevents the programmer making errors (presumably by auto-correcting everything he inputs) the programmer is no longer analysing why he needs to programme in specific styles. He may also stop thinking innovatively and ends up churning out standard "implement this complex logic" type programmes.

When you remove those safety nets the programmer must then continuously appraise the code he produces. He will look for sensible re-use, novel ways to simplify the application logic, improve factorisation and ultimately become a better craftsman programmer. His reward is not necessarily all in money terms but also in a great deal of self- satisfaction.

Allowing novice programmers to grow into true craftsmen will yield programmes that are well thought out, well designed, fully reviewed and as correct as can be obtained. This software will also be very maintanable and of very good quality. Also it can be achieved without very complex procedures or expensive tools.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

There was an item about this in Jack Ganssle's Embedded Muse (93). See

formatting link
for details.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

I remember that during my school days the teachers were very adept at making you realise how bad your mistakes were. They were also equally adept at showering praise when it was due. We were never made to feel small when our mistakes were pointed out.

Try an find a book called "The One Minute Manager" which I have found has a much better balance of the carrot and stick aproach.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

I'm afraid I was not able to find the article you mention. Do you have a title or a URL?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

When reviewing code, I mark multiple returns with a "justify" rather than a forbidden. In some cases it's the sensible thing to do, and if it can be justified it's fine.

I tend to dislike seeing returns scattered around complex code because it becomes increasingly difficult for a reviewer to ensure the flow of code is correct.

Reply to
Geoff McCaughan

Programmers aren't puppies. A puppy doesn't understand it when you try to explain what the bad dead was. A programmer is fully capable of understanding that the mistake they made three weeks ago is the cause of their current headache. (well, _some_ programmers are :-)

Programmers are also quite able to learn from the mistakes of others. Ie, assign them the task of fixing a program written by someone else, and they'll learn how bad style can result in an unmaintainable mess.

--
Darin Johnson
    I'm not a well adjusted person, but I play one on the net.
Reply to
Darin Johnson

If it's difficult to keep track of returns scattered around, then the function is too long :-) The easiest justification for some multiple returns is that it makes the code easier to read - reduces the amount of indentation, handle all the error cases at the start of the function, etc.

--
Darin Johnson
    "Particle Man, Particle Man, doing the things a particle can"
Reply to
Darin Johnson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.