Buried in warnings [LWN.net]

Buried in warnings

Posted Nov 2, 2006 8:39 UTC (Thu) by pcdavid (subscriber, #4295)
Parent article: Buried in warnings

Since version 1.5 and the addition of annotations, Java compilers support a @SuppressWarnings annotation. It can be attached to almost any element in the code (type, method, parameter, local variable, etc.) and is used to silence specific kinds of warnings related to this element. The exact kinds of warnings which can be silenced depend on the compiler, but some are mandatory. For example, if you have a pre-1.5 class which uses non-generic collections, you can add @SuppressWarnings("unchecked") to the class. This essentially tells the compiler "This class uses operations which might seem unsafe to you, but I know what I'm doing so don't bother me about it."

Couldn't the sparse tool be extended to support this kind of things? It could then filter out the output of GCC and remove the warnings which have been accounted for by the developers.

(Log in to post comments)

Buried in warnings

Posted Nov 2, 2006 10:39 UTC (Thu) by Asebe8zu (subscriber, #24600) [Link]

Another very useful feature in Java without equivalent in C
is the final modifier for local variables.
When used, the compiler ensures that the variable is set
once and only once before being used.

I don't know how you would implement this in C though, without
introducing some new keyword.

Java 'final', C 'const'

Posted Nov 2, 2006 15:20 UTC (Thu) by jreiser (subscriber, #11027) [Link]

If the final value is (or could be) assigned at declaration, then the C keyword const suffices.

My own favorite candidate for compiler enhancement is a message, "warning: 'const' omitted". The compiler detected that there would be no complaints if the programmer supplied the keyword const.

Java 'final', C 'const'

Posted Nov 2, 2006 21:16 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

The problem I run into time and time again with const in C is that there are too many functions in too many libraries which take a non-const pointer, even though they do not modify the pointed-to entity. Very annoying.

Pointer to pointer to const

Posted Nov 3, 2006 1:40 UTC (Fri) by xoddam (subscriber, #2322) [Link]

That would be a fine idea, if you didn't run into "C++ Gotcha #32" all the time when trying to do this (it's just as much a gotcha in C as it is in C++). As long as you don't try to take the address of your const pointer, you're safe. But you can't mix const and non-const indirect pointers, because of aliasing problems.

Of course said aliasing problems might all be hidden deep inside the library (and/or the imagination of the compiler) and users shouldn't have to care at all -- but if it causes a problem for the developer, they're far more likely to drop 'const' than to suppress compiler warnings with casts and hope everything is otherwise correct.