Re: nstrftime.c fails to build due to memset overflow

[Bruno Haible]

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