[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: nstrftime.c fails to build due to memset overflow
Date: Wed, 15 Mar 2023 15:42:49 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

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 comments like /* Initialize this variable to pacify gcc 13.1 x86-64 when compiled with -Wall -O2; see <>. */ is better, but it also gets in the way of code ability (and is so rarely done right that I hesitate even mentioning it). Making code hard to understand (and/or hard to write correctly) drives up maintenance costs and that makes bugs more likely.

This sort of code pollution is the tail wagging the dog. The goal should not be to pacify compilers' false alarms. The goal should be to have code that works correctly, is easy to understand, is efficient, etc.

We should of course encourage compiler-writers to write smarter compilers with fewer false alarms, and we can do that by filing bug reports (which I do) and getting these false alarms fixed (which does happen). This approach is better in the long run than polluting the source code.

If these sorts of false alarms were a real problem, we could disable them with the appropriate -Wno-... option, rather than polluting the code to work around them. However, the false alarms we're talking about, which occur when compiling with -O0 -Wmaybe-initialized warnings, are not worth worrying about. We can just ask people not to use that combination of options (since it's counterproductive) and we can leave the code alone. And that is what we should do here.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]