Some embedded developers just never got the memo about control flow constructs. You can find some truly bizarre and concerning development practices in the embedded world.

The reverse is true -- app developers see something "weird" in embedded code and think it must be wrong, but often there is a reason. E.g. the unintended vehicle acceleration scandals, where codebases were criticized for having large numbers of global variables... but it's because there's no allocation permitted, and message passing is more expensive than just setting a bit of memory in a massive cooperative multitasking loop.

You might see weird stuff in embedded code because it needs to interact with flakey hardware using a flakey compiler, and be cycle accurate in the process.

I get it. I’ve done enough systems program and reversed many more embedded systems, bug hunting for customers. There are still a lot of bad practices in the embedded world. It often exists outside of normal best practices. Many choices embedded devs make are just plain bad. Using outdated libraries and binaries from a decade or more ago, etc. it doesn’t have to be so bad. I haven’t found many embedded systems that weren’t really bad from a security perspective.

The way these systems get developed is a huge part of the problem. One team building hardware, another building the software no one communicating. Everyone hoping for the best. Frantic cleanup in software to make it all work on top of hardware thet can no longer change. I am sympathetic to the embedded developers position, but they still seem to exist in a different universe from modern software dev.

As a security practitioner I don’t blame the devs. I like to ask questions about how things got to be this way. How we can make it better. But make no mistake. A decade will pass and some embedded developer will still be linking some ancient binary or throwing together a bunch of sketchy CGI files that let an attacker scribble everywhere in memory. Embedded is like, the final frontier of software security :)

That’s my lens anyway :)

I work on embedded software and far more often there's no good reason. (the global variables thing is ambiguous: it could be just counting static variables with well-defined scopes and encapsulation, or it could be describing truely global variables which can be modified by any part of the code at any time. The former is a reasonable technique to seperate modules without allocation. The latter is hair-raisingly reckless software design and also probably the more common approach, even in safety-critical systems). The level of awareness of software engineering concepts in the embedded ecosystem seems far lower than other areas.

I think it's a symptom of the field. A lot of arduino code is ghastly but mostly comes down to hardware people coding things for the first time and having zero professional development experience or formal education.

Yes, well, some of us are working with barely more than what a Commodore VIC-20 had to offer. (And we like it!)

;)

The problem with C is that it doesn't have proper tail recursion, so if you want to use C as a target language for something that does have proper tail recursion, you pretty much have no choice but to make goto soup.

The C standard doesn't mandate tail-call optimization, but at least GCC and Clang are pretty good at doing it (-foptimize-sibling-calls, which is turned on with -O2)

That it is only an optimisation ensures it will eventually fail to trigger at the least convenient possible moment.

Unless your C implementation has TCE, don’t assume recursion is optimised.

> The problem with C is that it doesn't have proper tail recursion, so if you want to use C as a target language for something that does have proper tail recursion, you pretty much have no choice but to make goto soup.

Or you could, you know, use a normal loop...

Besides, since 2005 or thereabouts gcc with -O2 did proper tail-call optimisation so that the stack doesn't grow on a tail-call recursion.

Would that really happen though? I don't think I would actually release recursive code.

I find recursion to be very simple and elegant for prototyping algos, but I would instinctively rewrite it with an iterative/queue form as soon as the "toy" stage is over.

But why would you do that, if it's simple and elegant? Really the only answer is that it has potentially unbounded stack consumption - but tail recursion solves exactly that problem.

Not all recursive algorithms are tail recursive; not all tail recursive algorithms can be correctly identified & tail optimized.

Right, but OP was specifically talking about tail recursion.

goto would only help in cases of tail self-recursion, though.