(Apologies for the delayed response. I receive gcc-help posts, including
others from you, without problem, but this one which I'm particularly
interested got caught in my spam filters.)
On 10/24/20 11:32 AM, Segher Boessenkool wrote:
I have to disagree with you there. Well-factored code is *good*. The
compiler can (and will) do all the obvious optimisations; you should not
obfuscate your program by doing them manually (and hinder the compiler's
optimisers, and introduce bugs at the same time).
FWIW, I agree.
"Gratuitous functions" is only a problem if you have trouble naming
them. Which sometimes is a problem, sure, but most of the time that
simply shows that your factoring isn't so good.
I always factor out common code, and attempt to give it informative
function/class/method/namespace/etc names.
I tend *not* to factor out code that is only used in one place merely to
follow coding standards that forbid lengthy functions. No spaghetti
code, but I have no problem with:
void func()
{
// part1
// ...
// part2
// ...
// part3
// ...
}
compared to:
void func()
{
part1();
part2();
part3();
}
regardless how long the "parts" are (assuming they aren't reused elsewhere).
And, yes, I understand inline functions.
-Wmaybe-uninitialized only has false positives for non-trivial control
flow. Which you probably shouldn't have in your source code anyway.
Whether or not it gives false positives seems unpredictable. My code's
control flow is:
void func(
bool with_buffer)
{
char *buffer;
if (with_buffer)
buffer = allocate();
while (still_working()) {
other_processing();
if (with_buffer)
process_buffer(buffer);
yet_more_processing();
}
}
This test demo does not give the warning. The real program, with
identical control flow but much more intermediate code, does.
Yes, there are many ways to refactor this code (separate "with" and
"without" functions, two different loops inside "if" and "else" branches
of "if (with_buffer)", etc). IMO all of them obfuscate the above simple
control flow, not the opposite.
If you insist on using constructs that -Wmaybe-uninitialized cannot
handle, then do not use -Wmaybe-uninitialized?
I thought we agreed that warnings are A Good Thing.
It should arguably not be enabled by -Wall, just by -Wextra.
FWIW, I'm using -Wextra. As per above, I like warnings.
The only comment was a helpful suggestion. If that is not what you are
looking for, just ignore it, or make a comment yourself? Complaining
that people are "dismissive" because they have a different opinion is
not helpful.
The comment was "Why don't just initialize the variable?". In addition
to the unnecessary compiled instructions that produces (unless the
optimizer is smarter than the warning generator and removes them), it
hides the issue in a non-obvious way compared to the explicit pragmas or
a theoretical attribute.
As you point out, that's been the only comment in 8 years until this
discussion -- and I do consider it a discussion, not a "complaint". As
you said before, the issue is still open. I considered the comment a
"last word", which along with lack of further response to the original
issue filer's further points to mean, "we feel this is not
needed/important". Whether that's "dismissive" or not is open to
interpretation.
If you insist on having an attribute to disable just this warning, you
can implement it yourself (or get someone else to do it for you).
Of course.
It
does not have to become part of GCC mainline. *That* is the nature of
Free Software.
I'm suggesting the attribute because I want to use it in some
open-source software I'm distributing. I also think it would be a good
GCC extension in general. Even assuming I had the ability to implement
it myself or contract the same, I will not be distributing a custom
compiler for my project, so if it wouldn't make it into the mainline
(which these emails strongly suggest), that's not an option.
If you cannot convince people to spend their time on
implementing your ideas, then maybe they do not think those are good
ideas?
Obviously they/you don't. Pending any further comments regarding my
control flow example above, I'll take it that I wasn't convincing and
the matter is closed. I do take heart that others (like the 2012 issue
filer and some in this short thread) seem to agree with me, or at least
that this has been worth discussing.
