Hi Marcus, Please try to understand Paul's arguments.
> Sorry to respectfully contradict you here: introducing a macro really > doesn't do readability and immediate clarity of effect any better than > a commented zero-initialization. Apparently Paul and you have different ways of reading code, which leads to different measures of "readability". You two could keep contradicting each other eternally; that's not fruitful. > I consider code paths that intentionally differ between debug and release > builds detrimental to code quality This is a valid argument. But read the code that Paul proposed: It does not conditionalize on NDEBUG. It conditionalizes on GCC_LINT || lint. These macros can be turned on independently of NDEBUG. > Generally, when I (and I fully realize that this describes me, not > anyone else necessarily) read codes trying to understand bugs, I > dread macros. There's a big difference between macro-loaded code, as in e.g. https://gitlab.inria.fr/gustedt/p99/-/tree/master/p99 or https://github.com/LeoVen/C-Macro-Collections , and a simple UNINIT macro that Paul proposed, that does not even hamper debugging with gdb. > The original white_add macro which gcc falsely finds a -1 in, > which kicked off this thread? That should really not be part > of any code base. GCC would give the same warning if you would pass it the macro- expanded source code ("gcc -E" output). Therefore it is irrelevant whether white_add is a macro, a function, or entirely inlined. Bruno
