C function pointers : trick questions

Development Code
21

FMECA, really, but we use the French translation, AMDEC. The aero industry also relies on various best-practice databases that are essentially the result of every aircraft failure investigation done by national or international agencies like the FAA. Those exist for every field of engineering. For example there are entire tomes on the specific types of welds and riveting you shouldn’t use in specific applications, complete with the contexts where failures were observed, and the effects.

Those databases are probably the main reason the industry is super-conservative. If we don’t have a lot of RETEX on a technology or a process, it’s harder to certify and so we only use a new technology when there’s an actual will (and the money to back that will) coming from very high up. That’s also why it’s so hard for new companies to enter the business, and why COMAC doesn’t have foreign customers.

Yeah, that’s pretty insane from where I’m sitting. Speaking of dependencies, we don’t care for them too much. Whenever we release software, all the source code is archived independently of any repository, and we CRC everything for good measure. We even archive the toolchain we used to build a specific release. Everything is traced. Rebuilding a binary involves checking the result’s CRC against what’s been archived.

Such binaries are considered components, same as nuts and bolts. They get a serial number. That, and their CRC, is typically listed on the BOM for a calculator. And you can’t update it without taking the whole system apart. Forget OTA updates or BIOS tools to re-flash the firmware, the only route is usually a test fixture with a JTAG probe and it’s not something you do without lots of people being in the loop.

4 updates a week ? Besides development builds that never fly outside simulation, I haven’t had to update flight software 4 times in my entire career :sweat_smile: : you release, and you’re done. Next project. Sometimes a plane might get a “mid-life update” that might require new code here or there, but everyone does their best to try and avoid that, because a software update is very expensive. It’s sometimes easier to add a separate calculator for new functions than to modify something that works. All our git repos end with a single final release.

But hey, at least we don’t have to worry about bug reports and having to work overtime to push out a half-assed patch that will need its own patch the next day :grin:

22

Yeah I’ve had such a job at Parrot. Not the same safety constraints, of course, but they wanted to improve their code base. When they really cared more about meeting the Christmas sales deadline, I quit. That only lasted about three months.

1 Like
23

I’m a bit late here, but…

In “original” C (I say that because my usage of C goes back to the 80s and transitioned to C++ in the 90s), a function name is an address and a name followed by parentheses is a function call. C has its own argument list management in which it’s the responsibility of the caller to establish the parameter pack - register contents or stack frame, or combination thereof depending on the ABI - before and after the call to a function.

This is known as the C calling convention. In days gone by, particularly in the Microsoft world, and I daresay the Apple world (and other vendors’ worlds), the so-called Pascal calling convention would expect the callee to clean up any stack-based argument passing (it was all stack-based on Intel architecture then), because this produced smaller code (memory was tight!). Under the covers an Intel ret N instruction says to add N to the stack pointer on return, thereby tearing down any stack frames created before the call. This meant that the number and types (sizes) of arguments passed is much more stringent than with the C convention.

In C it’s up to the caller to pass in the correct number and types of arguments. If you pass in garbage, such as you pass fewer arguments than the called function is expecting, then you will get unexpected behavior, often a crash (sooner or later).

Lint, more stringent compiler warnings/errors, and the advent of sanity checking made it harder to unintentionally get wrong the call to functions (and return values). However, in C you can pretty much typecast anything to anything else to get around language or type-checker restrictions.

C++ is where the type system, including argument lists was really tightened up in the C-style programming world.

So, what you’re doing is perfectly allowed by C. And yes, it can create vulnerabilities, but that’s the power - and the drawback - of C. It is essentially a super-assembler that allows you full access to the underlying hardware, if you know what you are intending, and with large caveats of potential incompatibility and non-portability.

It’s unsurprising that the Linux kernel (and Windows kernel for all I know these days) is still written in C: it allows you to do exactly what you want, but it also allows you to get yourself into unexpected trouble if you’re not entirely clear about what you’re doing, and of course if you don’t make mistakes while doing it.

2 Likes