5 ms·
CERT C is a really good standard and book. But there's really no reason to read a book. It's very simple if you follow these steps. Step 1. NO CONSTANT NUMBERS
by maldev 4y ago
CERT C is a really good standard and book. But there's really no reason to read a book. It's very simple if you follow these steps.
Step 1. NO CONSTANT NUMBERS! All constants should be a define macro or a constant. This will allow you to change code without overflows and having to update the number in 20 places and not knowing what number to use when looping through.
Step 2. SESE(RAII in c++, but most use SESE even in c++). SINGLE ENTRY SINGLE EXIT. Your code should look like
"
int *ptr = foo();
if(ptr == nullptr)
DEBUG_PRINT("FAILED ALLOCATING PTR IN __FILE__ @ __LINE__)
goto exit;
EXIT:
if(ptr)
free(ptr);
....
"
So any allocations you cleanup in exit. This way you won't miss it with wierd control flows. This is reccomended by all cert c standards.
Step 3:
If you can, there's analyzers you can use that will point out all bugs by annotating your code. SAL is arguable the best in the industry and you can catch pretty much all bugs.
Step 4:
Even without an analyzer, you should be looking at all warnings and either adding a compiler macro to ignore it, or fixing whats causing it.
- jbms 4y agoHaving gotos is a big no no. Put the rest of the function in an else case if need be. https://www.perforce.com/blog/kw/NASA-rules-for-developing-safety-critical-code#:~:text=NASA%27s%2010%20rules%20for%20developing%20safety%2Dcritical%20code%20are%3A,dynamic%20memory%20allocation%20after%20initialization https://www.perforce.com/blog/kw/NASA-rules-for-developing-s....
- mrmuagi 4y agoC and gotos are common from what I've seen -- userspace and kernel C code deals with error handling and resource freeing easier that way. Open to see examples of (good) C code that doesn't use it though.
- Gibbon1 4y agoI used goto's fairly often to separate the happy path from the unhappy one. That's way better than confusing jumbles of if statements. if(something_bad) { err = BADTHING1; goto oops; } // more stuff return 0; oops: return err; I'll add 1. keep code that performs calculations separate from code that performs side effects. In fact isolate the latter as much as possible. 2. Avoid spooky action at a distance. Code should relentlessly work towards a clear goal.
- maldev 4y agohttps://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consi... Here's a copy of the CERT C standard. The site you linked is incorrect. If you google GOTO error handling. Or any of the sort it will come up with it. You should'nt use goto in literally any other case besides this though, which is what I( assume they were referencing.
- jbms 4y agoThanks, that's interesting. AUTOSAR C++14 guidelines don't allow goto in any case. MISRA C++ 2008 does have a couple of rules that allow this specific scenario. MISRA C:2004, "goto shall not be used". MISRA C:2012, it was weakened to "goto should not be used".
- wallscratch 4y agoLinux kernel has a bunch of gotos, primarily used to just jump to exit / deallocate on kmalloc failure, without having to unnecessarily complicate the control flow to handle that.
- anonymoushn 4y ago> Step 1. NO CONSTANT NUMBERS! All constants should be a define macro or a constant. This will allow you to change code without overflows and having to update the number in 20 places and not knowing what number to use when looping through. My radix sort now needs BUCKETS_PER_LEVEL_1BYTE, BUCKETS_PER_LEVEL_2BYTE, FIRST_BYTE_SHIFT_AMOUNT, (0x100, 0x10000, ((sizeof(x)-1)*8) respectively) etc. along with many of my mmaps needing NO_FD to replace -1