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,
On 3/15/23 16:03, Marcus Müller wrote:
introducing a macro really doesn't do readability
I don't want the macro either. Let's just leave the code alone.
I consider code paths that intentionally differ between debug and release builds
There's no need for that. Debug with the same options you
Hi Paul,
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.
I also disagree with your approach being less of a submission to the false (or
over-arching) compiler warnings
On 3/15/23 02:41, Marcus Müller wrote:
If my compiler doesn't optimize it away, well, then I have caused very
little overhead.
It's not really a question of overhead. Unecessary initializations make
code harder to understand. Polluting code with unnecessary
initializations together with comm
Hi Bruno,
thanks for picking this up! And also, about all the background you're giving; that's much
appreciated.
On 14.03.23 22:45, Bruno Haible wrote:
[CCing bug-gettext, since po/Makefile.in.in comes from GNU gettext.]
Thanks :) forwarding a patch is quite an endorsement.
msgmerge: do not
Hi Paul,
Uff, being a newb to this community, I feel really bad about giving my 2ct to roughly the
first thing I read on the mailing list, but:
Let's not do what GNU emacs does.
Having different code when linting and not linting makes bugs that only happen in
non-debug/lint builds impossible
