6 ms·

In previous embedded work, I've had to follow the MISRA C [0] guidelines, which I suspect are roughly similar to the JPL guidelines (but I can't get to the PDF

In previous embedded work, I've had to follow the MISRA C [0] guidelines, which I suspect are roughly similar to the JPL guidelines (but I can't get to the PDF at the moment due to the bad SSL cert). [0] https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C

guitarbill 8y ago
> Two earlier efforts have most influenced the contents of this standard. The first is the MISRA-C coding guideline from 2004 [...] Not just similar, but based on MISRA C! MISRA C can be a total PITA though (I get why, but it doesn't make it any less annoying). Some well known storage products follow similar principles without being quite so stringent. It's quite a nice middle ground, and - if you are, err, detail oriented - can be a less aggravating experience than sloppy, higher level codebases (yes, Java, I'm looking at you mainly).
- carlmr 8y ago
  MISRA C is annoying mostly if you have to change the codebase to fit the standard. If you iteratively solve MISRA warnings they become second nature and you almost don't make them anymore. What is annoying is the paperwork when you need a deviation. However that's kind of the point of the process. Make it annoying enough that people really think about whether the deviation is necessary. At the same time it's only a coding standard. Not a panacea for all your coding issues. You can have 100% MISRA conformant spaghetti. It does reduce the "shoot yourself in the foot" surface area a little bit though.
  - acprog42 8y ago
    > You can have 100% MISRA conformant spaghetti. IMHO some of MISRA rules lead directly to hard to read/maintain code. Consider a function that: 1. opens a file 2. allocates enough memory to store the whole file 3. reads the file 4. return the allocated buffer on success or NULL on failure You want to write it so it doesn't leak either memory or file handles whether successful or not (if successful ownership of the memory buffer is passed to the caller so it must not be freed in that case). To be MISRA compliant you'd either end up with a "Christmas tree" of nested scopes or if-statements with extra && in them (pseudo C-code): char *buf = NULL; FILE *fh = fopen(...); if (fh) { if (success(fseek(fh, end))) { long int sz = ftell(fh); if (sz > 0) { buf = malloc(sz); if (buf) { if (failed(fread(fh, buf))) { report_error(); free(buf); buf = NULL; } } else { report_error(); } } else { report_error(); } } else { report_error(); } fclose(fh); } else { report_error(); } return buf; However if you were allowed to use goto with a single exit-label the code would be much cleaner and easier to follow: char *buf = NULL; char *rv = NULL; FILE *fh = fopen(...); if (!fh) { report_error(); goto exit; } if (fail(fseek(fh, end))) { report_error(); goto exit; } long int sz = ftell(fh); if (sz <= 0) { report_error(); goto exit; } buf = malloc(sz); if (!buf) { report_error(); goto exit; } if (failed(fread(fh, buf))) { report_error(); goto exit; } rv = buf; buf = NULL; exit: if (fh) { fclose(fh); } if (buf) { free(buf); } return rv;
    - acprog42 8y ago
      Too little karma to edit and fix indentation. Anyway given the above functions, think about adding support for only returning the buffer if the file contains a specific word. While certainly doable in both cases I would at least feel more uncertain editing the first without accidentally creating a bug...
    - regularfry 8y ago
      If you allowed yourself a second label, you could clean up those repeated `report_error()` calls, too.
      - acprog42 8y ago
        True, it would be kind of analogue to try/except/finally if you do that.
    - Jedi72 8y ago
      I'm so glad I don't use C hahaha. Y'all are crazy!
    - carlmr 8y ago
      I completely agree. Most Misra software is embedded without dynamic allocation though, so you usually don't get into this situation too often. I think an exception here makes sense
      - acprog42 8y ago
        > Most Misra software is embedded without dynamic allocation though True, but I've seen enough MISRA code bases plagued with the "Christmas tree" layout even if dynamic memory allocation isn't allowed. This was just a generic example most people can relate to.
        carlmr 8y ago
        I just checked, and MISRA 2012 seems to allow goto again under certain preconditions (you have to have a label declared in the same function and it has to be in the same block). So actually you can do proper error handling again. Still single return statement, which usually makes for more spaghetti.
  - philpem 8y ago
    Definitely agree here. Shoehorning an existing codebase into being MISRA compliant is utter hell. It's something you really need to design-in from the beginning. Also for anyone in the audience who's going "ugh, MISRA..." -- the 2012 spec revision is a significant improvement on the 2004 version and cleans up a lot of the more troublesome rules. Even if I'm not doing MISRA-required code, I still find myself sticking to its suggestions... "Allocate memory statically" is a really good one, especially on embedded systems.

guitarbill 8y ago

> Two earlier efforts have most influenced the contents of this standard. The first is the MISRA-C coding guideline from 2004 [...] Not just similar, but based on MISRA C! MISRA C can be a total PITA though (I get why, but it doesn't make it any less annoying). Some well known storage products follow similar principles without being quite so stringent. It's quite a nice middle ground, and - if you are, err, detail oriented - can be a less aggravating experience than sloppy, higher level codebases (yes, Java, I'm looking at you mainly).

carlmr 8y ago
MISRA C is annoying mostly if you have to change the codebase to fit the standard. If you iteratively solve MISRA warnings they become second nature and you almost don't make them anymore. What is annoying is the paperwork when you need a deviation. However that's kind of the point of the process. Make it annoying enough that people really think about whether the deviation is necessary. At the same time it's only a coding standard. Not a panacea for all your coding issues. You can have 100% MISRA conformant spaghetti. It does reduce the "shoot yourself in the foot" surface area a little bit though.
- acprog42 8y ago
  > You can have 100% MISRA conformant spaghetti. IMHO some of MISRA rules lead directly to hard to read/maintain code. Consider a function that: 1. opens a file 2. allocates enough memory to store the whole file 3. reads the file 4. return the allocated buffer on success or NULL on failure You want to write it so it doesn't leak either memory or file handles whether successful or not (if successful ownership of the memory buffer is passed to the caller so it must not be freed in that case). To be MISRA compliant you'd either end up with a "Christmas tree" of nested scopes or if-statements with extra && in them (pseudo C-code): char *buf = NULL; FILE *fh = fopen(...); if (fh) { if (success(fseek(fh, end))) { long int sz = ftell(fh); if (sz > 0) { buf = malloc(sz); if (buf) { if (failed(fread(fh, buf))) { report_error(); free(buf); buf = NULL; } } else { report_error(); } } else { report_error(); } } else { report_error(); } fclose(fh); } else { report_error(); } return buf; However if you were allowed to use goto with a single exit-label the code would be much cleaner and easier to follow: char *buf = NULL; char *rv = NULL; FILE *fh = fopen(...); if (!fh) { report_error(); goto exit; } if (fail(fseek(fh, end))) { report_error(); goto exit; } long int sz = ftell(fh); if (sz <= 0) { report_error(); goto exit; } buf = malloc(sz); if (!buf) { report_error(); goto exit; } if (failed(fread(fh, buf))) { report_error(); goto exit; } rv = buf; buf = NULL; exit: if (fh) { fclose(fh); } if (buf) { free(buf); } return rv;
  - acprog42 8y ago
    Too little karma to edit and fix indentation. Anyway given the above functions, think about adding support for only returning the buffer if the file contains a specific word. While certainly doable in both cases I would at least feel more uncertain editing the first without accidentally creating a bug...
  - regularfry 8y ago
    If you allowed yourself a second label, you could clean up those repeated `report_error()` calls, too.
    - acprog42 8y ago
      True, it would be kind of analogue to try/except/finally if you do that.
  - Jedi72 8y ago
    I'm so glad I don't use C hahaha. Y'all are crazy!
  - carlmr 8y ago
    I completely agree. Most Misra software is embedded without dynamic allocation though, so you usually don't get into this situation too often. I think an exception here makes sense
    - acprog42 8y ago
      > Most Misra software is embedded without dynamic allocation though True, but I've seen enough MISRA code bases plagued with the "Christmas tree" layout even if dynamic memory allocation isn't allowed. This was just a generic example most people can relate to.
      - carlmr 8y ago
        I just checked, and MISRA 2012 seems to allow goto again under certain preconditions (you have to have a label declared in the same function and it has to be in the same block). So actually you can do proper error handling again. Still single return statement, which usually makes for more spaghetti.
- philpem 8y ago
  Definitely agree here. Shoehorning an existing codebase into being MISRA compliant is utter hell. It's something you really need to design-in from the beginning. Also for anyone in the audience who's going "ugh, MISRA..." -- the 2012 spec revision is a significant improvement on the 2004 version and cleans up a lot of the more troublesome rules. Even if I'm not doing MISRA-required code, I still find myself sticking to its suggestions... "Allocate memory statically" is a really good one, especially on embedded systems.