Modern C/C++ programming prefers perror() or returning error values, to using assert(). I understand this is because assert() often becomes a NOP in release binaries, and assert() can occasionally leak sensitive information.
Given that assert() is now frowned upon, could cppcheck update its rule checks to recommend suitable replacements in our source code files?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Assertions should never be used to verify the absence of runtime (as opposed to logic) errors, such as
Invalid user input (including command-line arguments and environment variables)
File errors (for example, errors opening, reading or writing files)
Network errors (including network protocol errors)
Out-of-memory conditions (for example, malloc() or similar failures)
System resource exhaustion (for example, out-of-file descriptors, processes, threads)
System call errors (for example, errors executing files, locking or unlocking mutexes)
Invalid permissions (for example, file, memory, user)
I don't know.. if there is for instance out of memory it might often be reasonable to just terminate directly. If you want to terminate directly then what is bad about an assert() ? The problem would be if the assert() is removed in release builds and you rely on it.. but there is no requirement to remove asserts in release builds.
Last edit: Daniel Marjamäki 2023-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Modern C/C++ programming prefers perror() or returning error values, to using assert(). I understand this is because assert() often becomes a NOP in release binaries, and assert() can occasionally leak sensitive information.
Given that assert() is now frowned upon, could cppcheck update its rule checks to recommend suitable replacements in our source code files?
I have not heard that
assert()should be avoided. If you have some references let me know.For now I am skeptic about writing a rule in Cppcheck. You could create your own rule file for this easily.
Personally I do not agree that assert should be avoided, but well I do not agree about all best practices.
How do you think about to take another look at information from articles like the following?
Will changes on your analysis tool adjust any views on questionable programming practices?
We should check that assertions are not used to assert environment-dependent conditions.
Do you mean environment variables or the build or run platform ?
If I write code that I know does not work on 64 bit architectures, and someone compiles it for a 64bit machine I would like the user to be told.
yes I agree however that would ideally be asserted at compile time so it can't be built.
as I understand this discussion it's about asserts at runtime.
The MSC-11 says:
I don't know.. if there is for instance out of memory it might often be reasonable to just terminate directly. If you want to terminate directly then what is bad about an assert() ? The problem would be if the assert() is removed in release builds and you rely on it.. but there is no requirement to remove asserts in release builds.
Last edit: Daniel Marjamäki 2023-06-01