Normally you turn assert() off for production buids, so it's not a robust solution, as some error conditions may not get generated in testing.
The memory protection catches a lot of out-of-bounds memory references pretty well, and if you enable core dumps, you can extract neat backtrace from the core file (provided your routines fail-forward in case of invalid arguments). Moreover, some compilers can be instructed to instrument your code & data, including stack, with guard data, meant to trip process if it accesses wrong memory region. GNU malloc does some guardians if you sest $MALLOC_CHECK_.
If you aren't worried about vendor lock-in, you can use GCC's __attribute__((warn_unused_result)) [1]
Comments
Normally you turn assert() off for production buids, so it's not a robust solution, as some error conditions may not get generated in testing.
The memory protection catches a lot of out-of-bounds memory references pretty well, and if you enable core dumps, you can extract neat backtrace from the core file (provided your routines fail-forward in case of invalid arguments). Moreover, some compilers can be instructed to instrument your code & data, including stack, with guard data, meant to trip process if it accesses wrong memory region. GNU malloc does some guardians if you sest $MALLOC_CHECK_.
If you aren't worried about vendor lock-in, you can use GCC's __attribute__((warn_unused_result)) [1]
--
[1] http://sourcefrog.net/weblog/software/languages/C/warn-unuse...
And if you are worried about vendor lock-in, you can hide it behind a #define