On 24/08/2025 22:42,
boltar@caprica.universe wrote:
On Sun, 24 Aug 2025 14:45:12 +0200
David Brown <david.brown@hesbynett.no> gabbled:
On 23/08/2025 16:26, boltar@caprica.universe wrote:
On Sat, 23 Aug 2025 16:15:03 +0200
David Brown <david.brown@hesbynett.no> gabbled:
meant "all warnings" when it was first introduced, but these days
there are hundreds of warning flags in gcc, and /nobody/ wants them
all enabled.
Presumably "nobody" is defined in a similar way as "all". It almost
no one
but some people will. I'm one of them.
I very much doubt that you are.
Do you want a warning when you write "float x, y; x = y + 2.5;" ? Do
you want a warning when you write "char x; x = x + 1;" ? Do you want a
Do I want a warning about using uninitialised variables? Umm, let me think...
.. yes please!
Yes, of course - those are obvious (but I should have been clear about
that). I meant warnings on promotion of single-precision float to double-precision (in "x = y + 2.5;") and warnings about converting "int"
to "char" in "x = x + 1;".
These are both useful in some types of programming, but not in most programming.
warning for "printf(s);" instead of "printf("%s", s);" ? Do you want a
Why would that produce a warning?
You get that if you have "-Wformat-security" enabled. Some programs get strings from an external source (such as files of messages in different languages). If these are used as the first parameter of a printf()
without careful sanitisation, they could be an attack surface by causing
stack corruption.
Some people (such as myself) want warnings on double precision
promotion, typically because they are using small limited
microcontrollers. Others want extra security on printf, typically
because they read the format strings from external sources. Very few
people will want both.
warning for all "switch" statements which don't have a "default" case?
Happens already.
No it doesn't, unless you enable it specifically (on gcc anyway - I
can't answer for clang or other tools). "-Wswitch-default" is not
enabled by "-Wall", "-Wextra", or by default.
Do you want a warning on "int * p = 0;" ? Do you want to warn about
constructs that are not present in C or C++ standards other than the
one you have chosen?
Yes, otherwise I wouldn't have specified a particular version.
The warning on "int * p = 0;" occurs if you have "-Wzero-as-null-pointer-constant" enabled. Most C and C++ programmers
are quite happy to use the literal 0 as a null pointer constant, but
some consider it risky and want a warning, forcing the use of NULL or
nullptr.
As for warnings about incompatibilities across standards versions, I
think you have completely missed the point.
If I want to write code in C11, I write "-std=c11", and I write my code
in C11. I have picked that standard because I want to use features that
are in C11 but not in C99 or earlier versions. I am not interested in
whether or not my code can also be compiled with C99 or C90. I /might/
be interested in known compatibility issues with C17 or C23. Similarly
for C++ standards. I suspect the same applies to you.
So I do not want warning flags telling me about using features that are
not available in different standards, or that my use of "auto" in C23 or
C++11 is incompatible with its use in earlier standards. I do not want warnings that my C code is not compatible with C++ - if I had wanted C++ compatibility, I would have written C code.
Of course some people /do/ want to write code that is compatible across
a range of standards, so the various "-Wxxx-compat" flags in gcc are
helpful to them. It is highly unlikely, however, that they will want
all these flags on at the same time.
Of course you are free to enable as many warnings as you like when you
use gcc. But before the gcc developers would bother implementing a
"-Wabsolutely-everything" flag, they'd have to be persuaded that it
would actually be useful to developers, worth the effort of
implementing it, and worth the cost of the consequences of it (such a
flag would limit the possibilities for flags that are not simply
on/off). I have seen discussions on the gcc mailing lists about a
clang-style "-Weverything" flag for gcc, and read about why it is
considered something of a joke flag in clang and only really of use
when testing the compiler.
"all" should mean all, not almost all, or the ones considered useful.
There was nothing stopping them using a different flag, eg -Wstandard
or something like that for the kind of warnings considered useful.
Then "-Wall" would be useless.
And yes, there /are/ things stopping gcc developers from changing flag
names without very good reason - it is effort on their part that could
be better spent on useful things, and it is effort on the part of all
their users that would then have to change their build scripts and flags
to match the pointless changes.
I have explained to you why "-Wall" has the name it does, and what it
means. I have explained why it does /not/ mean "all warnings", and why enabling "all warnings" would be of no serious use to anyone. If you
want to stay upset about this and continue to be annoyed about the name
of the flag, that's your choice - but at least you should no longer be
doing so from a position of ignorance. And if you want to file a bug
about it in the gcc development bug tracker, or write a patch for gcc to
get the flag names you want, you are free to do so.
handled in some way, and not just ignored. A "give me everything"
flag that floods the output with false positives is only marginally
better than no warnings at all.
Gcc standard warnings have nothing on the gibberish the C++ compiler
spits out
when there's a template error. Why the compiler writers think 3 pages of unintelligable crap is a useful tool in order to find what usually turns
out
to be a simple typo i have no idea. Clang is far better , though still far from perfect.
That is a red herring, completely irrelevant to the argument you have
been trying to make.
But it is also an issue that every C++ compiler has had trouble with
since the dawn of C++ templates.
And like many C++ compilers, gcc has been getting steadily better at
this, with later versions give better (or at least, less bad) error
messages than earlier versions. Some compiler options can help tune
behaviour to suit the user. You can also combine gcc's newer parseable
error formats with some IDE's to get a clearer picture. And you can use concepts (C++23) to significantly improve template error handling.
Didn't know about Weverything, just tried it and its actually found a
minor bug
in a program I'm working on atm.
Then you might want to look at the available warning options in
whatever compiler(s) you use, and start enabling them in your build
system.
Life is too short to google all possible warning flags and figure out which ones I need.
But it is long enough to rant about how the warning flags don't suit
your needs? Okay...
--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)