You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• On C Sequence Points
• A Code Port
• More on Low-Power Design
• Failure of the Week
• This Week's Cool Product
• Jobs!
• Joke for the Week
• About The Embedded Muse

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded" in the subject line your email will wend its weighty way to me.

"The secret of getting ahead is getting started. The secret of getting started is breaking your complex, overwhelming tasks into small manageable tasks, and then starting on the first one." Mark Twain.

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

While it’s easy to brush C off as a super-assembly language it's actually quite rich, expressive and has some dark holes that elude too many developers. Indeed, the C99 standard is over 500 pages long, is rather cryptic, and reading it is a sure cure for the worst case of insomnia.

Consider the following:

a =  ++b + ++c;

What does it do?

No one knows. The C standard leaves the details up to the compiler writer. It does define the notion of "sequence points," which are nodes where, as the standard states, "At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place."

The standard lists where sequence points will occur. Note that there are no sequence points within the assignment statement listed above. Whether the result is the sum of the two variables in their incremented or non-incremented states (or with variable a or b incremented and the other not) is entirely undefined.

Common software standards emphasize this ambiguity. MISRA Rule 12.13 states: "The increment (++) and decrement (--) operators should not be mixed with other operators in an expression."  But the explanatory text says "The use of increment and decrement operators in combination with other arithmetic operators is not recommended..."

The assignment operator is not an arithmetic operator (it’s defined, logically, as an "assignment operator" in the C standard). So MISRA apparently permits:

a[i++]  = i;

...even though the result is undefined, as cryptically noted in the C99 standard: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored."

As a footnote in the standard notes, this means:

i=++i;

results in unspecified behavior, though of course the logically-equivalent operation:

++i;

is just fine.

CERT rule EXP30-C is much stronger than the MISRA rule: "Do not depend on order of evaluation between sequence points." In fact, the standard lets compilers evaluate parts of an expression with all of the discipline of sailors at a bar on shore leave. It says "The order in which subexpressions are evaluated and the order in which side effects take place, except as specified for the function-call (), &&, ||, ?:, and comma operators" is unspecified.

Many developers think that precedence rules determine which part of an expression gets evaluated first, but that's not necessarily the case. In the expression

fa() + fb() * fc()

it's perfectly acceptable for the compiler to evaluate fa() first. And adding even a Lisp-like swarm of parenthesis doesn't change anything. We have to rely on the rules of sequence points if evaluation order is important. There's a fantastic description of this issue here: http://www.eskimo.com/~scs/readings/precvsooe.960725.html.

CERT's software standard explicitly addresses sequence point issues in macros. Rule PRE12-C says: "Do not define unsafe macros." An example given is:

#define  ABS(x) (((x) < 0) ? –(x) : (x))

e.g.:

m = ABS(++n);

Which will expand to:

m =  (((++n) < 0) ? -(++n) : (++n));

And that clearly has no sequence points so its behavior is unpredictable.

The logical AND (&&) operator does specify a sequence point, but it, and the logical OR, have another twist. The standard reads: "Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated." (There’s a similar statement for logical OR.)

That means code like:

if ((  i == num) && (( j++) > 0){code};

...will not always increment variable j.

CERT warns developers about this sort of code via rule EXP-02-C: "Be aware of the short-circuit behavior of the logical AND and OR operators."

Obviously developers have to be very aware of these sorts of issues to develop reliable code. But there’s another issue:some companies ask sequence point questions on tests for prospective employees.

Few applicants get the answers right.

A reader who wishes to remain anonymous writes:

In response to last issue's article on battery-operated systems, Josh wrote:

John Taylor wrote:

Steven Stewart asked Alexa a question:

And this is from Chris Gates:

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Microsoft is placing the ThreadX RTOS and all the middleware into open source under the Eclipse Foundation stewardship.  Here is the Microsoft announcement:

https://techcommunity.microsoft.com/t5/internet-of-things-blog/microsoft-contributes-azure-rtos-to-open-source/ba-p/3986318

An group named RTOSX has been formed dedicated to support current ThreadX customers as well as those that will take the open source version in the future. Here is our PR on the subsidiary:

https://px5rtos.com/press/px5-commits-to-long-term-value-for-threadx-developers-with-spin-off-of-rtosx-subsidiary/

You can get find some more details here:   rtosx.com

Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors.

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

These jokes are archived here.

Contrary to popular belief, you don't become a geek because you're smarter than everyone else. You become a geek because your social skills are retarded. While you're off administering a Linux system, the rest of us are necking. So the tech support folk can be as snide as they want. The minute the clock strikes 5, we win.

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.