GHS C++: extra semicolon diagnostic message - purpose?

Question

In the GHS compiler, if you have multiple semicolons in a row without any intervening statements, this generates a diagnostic message (warning). For example:

void myfunc()
{
}; // warning #381-D: extra ';' ignored.

This doesn't seem like a very common situation, but this warning is also issued after preprocessing has occurred, such that, the following would also generate the warning (when compiled in release):

#if _DEBUG
  #define DEBUG_VAR(x) x
#else
  #define DEBUG_VAR(x) 
#endif

void myfunc()
{
}
// global variable, used only in debug
DEBUG_VAR(int x); // warning #381-D: extra ';' ignored.

I realize that there are easy ways to workaround this in this case, it is just an illustrative example. There are many other situations with the preprocessor where you might end up with a similar construct.

Obviously, the code is legal c++, and I have never encountered such a warning message on any other compiler I have used. Is there some reasonable explanation of why this warning would be helpful, for example, is there a specific case where this warning might indicate a programming error?

Answer 1

Is there some reasonable explanation of why this warning would be helpful, for example, is there a specific case where this warning might indicate a programming error?

Most cases, surely?

Since the ; has no meaning, either you wrote it as a redundancy (and then you have to ask "why?") or — and this is the key — you wrote it by accidentally deleting some code before it, or by getting something else wrong that confused the parser and made the ; look like it were redundant when, in fact, it weren't.

Off the top of my head, though, I can't think of an example.

But that macro would be better written like so:

#include <type_traits>
#ifndef NDEBUG
   #define DEBUG_VAR(T, N) std::common_type<T>::type N;
#else
   #define DEBUG_VAR(T, N)
#endif

void myfunc()
{}

// global variable, used only in debug
DEBUG_VAR(int, x)

Answer 2

My favourite example is the "persistent semicoloner". We had one at my last place of employment. More than twice he wrote:

for (i=0; i<MAX; ++i);
    a[i] = 0;

...and was then stymied that his array wasn't initialised. And worse, he had a bug where a random variable was corrupted.

If you can't spot it, wouldn't it be nice if the compiler did?

Having said all of that, I'll agree that often a stray semicolon is "tame" - but the logic that makes a compiler spit out the error in one place doesn't discriminate in others...