50 ms·

I don’t get the whole MISRA requirement that functions should only have one exit point. Honestly, nobody has been able to explain why this is important, other t

I don’t get the whole MISRA requirement that functions should only have one exit point. Honestly, nobody has been able to explain why this is important, other than it’s a historical anomaly inherited from FORTRAN. (Which was actually for a good reason)

dark-star 2y ago
one reason I can think of from the top of my head (although I never had to deal with MISRA C at all) is that if you have to add some cleanup code before your function returns, then there is exactly one place and one place only to do that. Otherwise this leads to duplication of cleanup code similar to allocate_something() .. if failed(foo) { deallocate_something() return FAILED; } .. deallocate_something() return SUCCESS;
- samatman 2y ago
  This is, more than anything, an argument for a `defer` statement, of the sort you can enjoy in Zig right now. Or hopefully, eventually, in C, thanks to the tireless efforts of JeanHeyde Meneide: https://thephd.dev/just-put-raii-in-c-bro-please-bro-just-one-more-destructor-bro-cmon-im-good-for-it https://thephd.dev/just-put-raii-in-c-bro-please-bro-just-on...
  - layer8 2y ago
    MISRA C can’t mandate new language features though.
    - AlotOfReading 2y ago
      The MISRA people work with the C/C++ committees on upcoming language changes, which gives them loud voices to push things they want promoted.
  - eddd-ddde 2y ago
    > certain name manglings are not guaranteed to be 1:1 and can infact “demangle” into multiple different plausible entities. Now I'm really curious, doesn't that mean some valid C++ code would fail to link for having multiple definitions of the same symbol?? I would expect name mangling to be a bijection from function prototype to string.
pklausler 2y ago
FORTRAN II introduced the RETURN statement.
- bee_rider 2y ago
  Languages like Matlab, where the values returned are listed at the top of the function and you don’t even need a return statement to tell it what to return, always feel so funky and fun.
layer8 2y ago
This is an old rule from when structured programming was introduced. The prior state of affairs was that code would jump via gotos between functions to different labels within those functions (labels were global). The requirement that every function should have only a single entry point and a single exit point seemed like a good rule to establish sanity. MISRA C states the following rationale: “A single point of exit is required by IEC 61508 and ISO 26262 as part of the requirements for a modular approach. Early returns may lead to the unintentional omission of function termination code. If a function has exit points interspersed with statements that produce persistent side effects, it is not easy to determine which side effects will occur when the function is executed.” Note that the MISRA C rule is merely advisory, meaning it is a recommendation and not a hard requirement (i.e. it’s a “should” and not a “shall”).
AlotOfReading 2y ago
That's one of many rules in MISRA that originate from antiquated "best practices" from the dark ages that don't actually improve safety. We have it today by way of IEC 61508, which gets it from a book on structured programming called Structured Design. That book didn't recommend banning multiple exit points, but it recommended minimizing them to simplify the control flow graph and said code should minimize the distance between black boxes (bits of code that do something without leaky abstractions and have only one return statement). The IEC authors and MISRA thought the logical extension of that was to make everything have one exit point.
- elcritch 2y ago
  I recall reading a study showing that MISRA actually tended to _increase_ the average number of bugs in software projects.
aulin 2y ago
the abominations I've seen in code review from people trying to fullfil this rule still wake me up at night
- daghamm 2y ago
  Yeah, in this particular case MISRAC is doing more harm than good. I wish we could get an update on these rules, but this issue has been brought up many many times bwfore and has always been brushed away without a proper analysis.
champijone 2y ago
One reason to prefer it in C is to be able to easily add locally scoped functionality like profiling markers and temp allocators. profile_begin("func"); a = temp_arena_begin(); // ... code temp_arena_end(); profile_end();
gwd 2y ago
Having been only lightly exposed to MISRA, my impression is that in MISRA the "Required" label doesn't mean "You must always do this"; rather it means, "You must do this or document why it's necessary and safe not to do it". It's a bit like an operating system write-protecting pages. Sometimes you write-protect pages that the process really shouldn't write to, like shared libraries or something like that. But sometimes you write-protect pages that you actually expect a program to write to, like memory-mapped pages, because then when the write happens it triggers something else (like copy-on-write or marking a page dirty or something). Rules like "Don't use dynamically allocated memory" are one example of this -- not that they really expect you never to do it, but that marking it "Required" is a way to force you to document how you plan to make it safe. Similarly, if it's easier to rearrange a function to have only a single exit point than to explain why you need multiple exit points, just rearrange it; you really need multiple exit points, just document why.
- rcxdude 2y ago
  This is true, in most of these things you can document your way around the problem, though sometimes you also have a third-party to convince who may or may not be reasonable. But either way, MISRA is a collection of stating the obvious ("don't do things the language says you shouldn't do" is like fully half of the list) and arbitrary restrictions that have little justification, so the fact that you can document your way around it still basically means you're doing extra work for no real benefit (because it's real difficult within such a conservative field to say "hey, that industry standard? It's crap, has always been crap, and we're going to ignore it").
actionfromafar 2y ago
Lots of MISRA could is proprietary and receives no upstream patches from customers. Still, it's not unusual to deliver a source blob to your customer instead of a binary blob, often for debugging. (But sometimes only the binary blob has the blessing of the vendor, so you can only use the binary blob in your released product) I would not be in the least surprised if someone has a compiler/transpiler from a higher level language to some C code which checks all MISRA boxes.

dark-star 2y ago

one reason I can think of from the top of my head (although I never had to deal with MISRA C at all) is that if you have to add some cleanup code before your function returns, then there is exactly one place and one place only to do that. Otherwise this leads to duplication of cleanup code similar to allocate_something() .. if failed(foo) { deallocate_something() return FAILED; } .. deallocate_something() return SUCCESS;

samatman 2y ago
This is, more than anything, an argument for a `defer` statement, of the sort you can enjoy in Zig right now. Or hopefully, eventually, in C, thanks to the tireless efforts of JeanHeyde Meneide: https://thephd.dev/just-put-raii-in-c-bro-please-bro-just-one-more-destructor-bro-cmon-im-good-for-it https://thephd.dev/just-put-raii-in-c-bro-please-bro-just-on...
- layer8 2y ago
  MISRA C can’t mandate new language features though.
  - AlotOfReading 2y ago
    The MISRA people work with the C/C++ committees on upcoming language changes, which gives them loud voices to push things they want promoted.
- eddd-ddde 2y ago
  > certain name manglings are not guaranteed to be 1:1 and can infact “demangle” into multiple different plausible entities. Now I'm really curious, doesn't that mean some valid C++ code would fail to link for having multiple definitions of the same symbol?? I would expect name mangling to be a bijection from function prototype to string.

pklausler 2y ago

FORTRAN II introduced the RETURN statement.

bee_rider 2y ago
Languages like Matlab, where the values returned are listed at the top of the function and you don’t even need a return statement to tell it what to return, always feel so funky and fun.

layer8 2y ago

This is an old rule from when structured programming was introduced. The prior state of affairs was that code would jump via gotos between functions to different labels within those functions (labels were global). The requirement that every function should have only a single entry point and a single exit point seemed like a good rule to establish sanity. MISRA C states the following rationale: “A single point of exit is required by IEC 61508 and ISO 26262 as part of the requirements for a modular approach. Early returns may lead to the unintentional omission of function termination code. If a function has exit points interspersed with statements that produce persistent side effects, it is not easy to determine which side effects will occur when the function is executed.” Note that the MISRA C rule is merely advisory, meaning it is a recommendation and not a hard requirement (i.e. it’s a “should” and not a “shall”).

AlotOfReading 2y ago

That's one of many rules in MISRA that originate from antiquated "best practices" from the dark ages that don't actually improve safety. We have it today by way of IEC 61508, which gets it from a book on structured programming called Structured Design. That book didn't recommend banning multiple exit points, but it recommended minimizing them to simplify the control flow graph and said code should minimize the distance between black boxes (bits of code that do something without leaky abstractions and have only one return statement). The IEC authors and MISRA thought the logical extension of that was to make everything have one exit point.

elcritch 2y ago
I recall reading a study showing that MISRA actually tended to _increase_ the average number of bugs in software projects.

aulin 2y ago

the abominations I've seen in code review from people trying to fullfil this rule still wake me up at night

daghamm 2y ago
Yeah, in this particular case MISRAC is doing more harm than good. I wish we could get an update on these rules, but this issue has been brought up many many times bwfore and has always been brushed away without a proper analysis.

champijone 2y ago

One reason to prefer it in C is to be able to easily add locally scoped functionality like profiling markers and temp allocators. profile_begin("func"); a = temp_arena_begin(); // ... code temp_arena_end(); profile_end();

gwd 2y ago

Having been only lightly exposed to MISRA, my impression is that in MISRA the "Required" label doesn't mean "You must always do this"; rather it means, "You must do this or document why it's necessary and safe not to do it". It's a bit like an operating system write-protecting pages. Sometimes you write-protect pages that the process really shouldn't write to, like shared libraries or something like that. But sometimes you write-protect pages that you actually expect a program to write to, like memory-mapped pages, because then when the write happens it triggers something else (like copy-on-write or marking a page dirty or something). Rules like "Don't use dynamically allocated memory" are one example of this -- not that they really expect you never to do it, but that marking it "Required" is a way to force you to document how you plan to make it safe. Similarly, if it's easier to rearrange a function to have only a single exit point than to explain why you need multiple exit points, just rearrange it; you really need multiple exit points, just document why.

rcxdude 2y ago
This is true, in most of these things you can document your way around the problem, though sometimes you also have a third-party to convince who may or may not be reasonable. But either way, MISRA is a collection of stating the obvious ("don't do things the language says you shouldn't do" is like fully half of the list) and arbitrary restrictions that have little justification, so the fact that you can document your way around it still basically means you're doing extra work for no real benefit (because it's real difficult within such a conservative field to say "hey, that industry standard? It's crap, has always been crap, and we're going to ignore it").

actionfromafar 2y ago

Lots of MISRA could is proprietary and receives no upstream patches from customers. Still, it's not unusual to deliver a source blob to your customer instead of a binary blob, often for debugging. (But sometimes only the binary blob has the blessing of the vendor, so you can only use the binary blob in your released product) I would not be in the least surprised if someone has a compiler/transpiler from a higher level language to some C code which checks all MISRA boxes.