 |
Our product makes use of a \"service-based\" architecture - and, while it is \"good code\" that runs on 16, 32, and 64 bit environments, it wasn't initially written with MISRA compliance in mind, although we're \"pretty close\". The tricky one is Rule 104...
Anyway, since networking, IPC, and other typical PC-and-up options for doing services aren't often available in constrained embedded environments, we've chosen function pointers and a \"registration\" methodology as our approach. We're an ISV that works with customers who typically write services themselves or use one of several service implementations that we provide. Services are things like file-system API interfaces, flash I/O interfaces, memory management, etc.
So, I have a question about Rule 104: it would seem that Rule 104 disallows this sort of approach, if I read it right: services are ultimately dynamically-created structures that contain arrays of function pointers that execute the different operations of the service.
The only \"get out of jail free\" card that I can see is that these pointers are set only once at registration time and not changed while the instance of the service exists. But the function pointers are initialized at runtime, so it would seem that we're still in violation of Rule 104.
Is \"initialized at runtime\" versus \"initialized at compile-time\" the test for Rule 104 compliance? Or is it \"a function pointer that is changed\", versus one that is initialized once, whether at compile or runtime, and not changed afterward?
|
