Are there any categories to characterize warnings?

Question

My empirical assumption of what compilers warn about in C-Code was actually that they warn the kind of behaving which is implementation defined, or in cases where they detect an construct causing undefined behavior, which they support nevertheless (if they detect and wouldn't they'd throw an error over just warning).

After I had an discussion about this the final proof that I was wrong was this:

#include <whatever_this_needs.h>

int main()
{
    int i = 50;
    return 0;
}

The compiler obvious warned about i was declared but never used. I wasn't thinking about this kinds of warning anymore, since I was seeing them more as kind of a tool.... an information.

While I would strictly dissociate this kind of warning from something that warns me about causing inportability or droping significance without explicit cast, it is still something that can cause confusion by compiler optimizations.

So I'm now interested: Are there any categorizations of warning types? If no standards about it are existing, what are the categories, GCC groups their warnings in?

What I noticed so far (empirical again):

• Warnings about:
  • implementation- / un- defined behaving
  • unnecessary code (targeted for optimization)
  • breaking of optional standards (i.e. MISRA or POSIX)

But especially the 2nd point bothers me, since there are constructs (i.e. strict aliasing rules) where optimization can even result in unpredicted runtime behaving, while most cases it just cuts away code that isn't used anyway.

So are my points correct? And what (additional) official categories are there you can 'typecast' warnings in, what are their characteristics, and what is their impact?

Answer 1

Warnings are beyond the scope of the C standard, so there are no requirements or specification for how they should behave. The C standard is only concerned about diagnostics, as in diagnostic messages from the compiler to the programmer. The standard doesn't split those up in errors and warnings.

However, all compilers out there use errors to indicate direct violations of the C standard: syntax errors and similar. They use warnings to point out things beyond what is required by the C standard.

In almost every case, a warning simply means "oh by the way, you have a bug here".

---

Regarding GCC (see this), it just categories warnings in:

• Things that are direct violations against the C standard but valid as non-standard GNU extensions (-pedantic)
• "A handful of warnings" (-Wall). Enable all warnings, except some...
• "A few warnings more" (-Wextra)
• Plus numerous individual warnings with no category.

There's no obvious logic behind the system.

Note that GCC, being filled to the brim with non-standard extensions, have decided just to give warnings instead of errors for some C standard violations. So always compile with -pedantic-errors if you care about standard compliance.

Regarding implementation-defined behavior: C contains a lot of this, it would get very tedious if you would get a warning for every such case ("warning: two's complement int used"...). There's no relation between implementation-defined behavior and compiler warnings.

Regarding any case of undefined behavior, the compiler is often unable to detect it, since the definition of UB is runtime behavior beyond the scope of the standard. Therefore the responsibility to know about and avoid UB lies on the programmer.