7

Cppcheck (version 1.46.1) gives the following warning for an enum like this one:

enum DATABASE_TYPE
{
    DATABASE_TYPE_UNKNOWN = -1, // <- line of warning
    DATABASE_TYPE_ORACLE,
    DATABASE_TYPE_MSACCESS
};

Redundant code: Found a statement that begins with numeric constant

I don't think, that it's redundant. It's quite important to be able to do things like that.

Is this an error of cppcheck or am I not seeing something?

Update

I managed to boil it down to a minimal example. This was complicated by cppcheck having 2 (further) bugs which made it look like my reductions had no effect.
There are 5 files: a.h, a.cpp, b.h, b.cpp and inc.h with the following content.
VC9 compiles it without warnings (warning level 4).

// a.h
#pragma once
#include "inc.h"

// a.cpp
#include "a.h"
#include "b.h"

int main()
{
    return 0;
}


// b.h
#pragma once
#include "inc.h"

// b.cpp
#include "b.h"

//inc.h
#pragma once

enum MY_ENUM_TYPE
{
    INVALID_VALUE = -1,
    FIRST_VALUE,
    SECOND_VALUE
};

So by now I'm pretty confident that it's a bug of cppcheck. Any diverging opinions?

foraidt
  • 5,519
  • 5
  • 52
  • 80
  • Yes, this seems like a cppcheck bug - #pragma once is not working. If you replace it with #ifndef A_H / #define A_H / #endif header wrapping, cppcheck does not complain anymore. – Johan Kotlinski Feb 02 '11 at 14:37
  • 1
    This also seems like a recognized problem: http://sourceforge.net/apps/trac/cppcheck/ticket/2417 – Johan Kotlinski Feb 02 '11 at 14:38
  • @kotlinksi: If you updated your answer with this, I could mark it as accepted. – foraidt Feb 02 '11 at 16:31

2 Answers2

6

My guess is, either:

A) invalid somehow is declared or defined elsewhere.

B) the enum is defined in a header included twice (without header guards). Because you get the same error for this code:

enum SomeEnumType
{
    invalid = -1,
    first,
    second,
};

enum SomeEnumType
{
    invalid = -1, // <- line of warning
    first,
    second,
};

Does your code compile with GCC?

UPDATE:

Yes, this seems like a cppcheck bug - #pragma once is not working. If you replace it with #ifndef A_H / #define A_H / #endif header wrapping, cppcheck does not complain anymore.

This also seems like a recognized problem.

Johan Kotlinski
  • 25,185
  • 9
  • 78
  • 101
  • `invalid` is just an example. In reality it looks more like `invalidSomeEnumType` so it's pretty unique. – foraidt Feb 02 '11 at 09:39
  • 2
    @foraidt: It's really a waste of time to ask questions about fake code. Post the real code so we can solve real problems. – GManNickG Feb 02 '11 at 09:40
  • @foraidt: Try creating the minimal example that will give the error, then it will be pretty clear what the problem is. Anyway, it is not a problem that you are giving it the value -1, the problem is that cppcheck thinks `invalid` is already defined. If you find there is a bug in cppcheck, report it to developers, they will fix it quickly. – Johan Kotlinski Feb 02 '11 at 09:45
  • @GMan: It's updated. But I doubt that it's of any more use now. One still can't tell whether the "invalid" part is defined multiply without checking the entire codebase. – foraidt Feb 02 '11 at 09:52
  • @kotlinksi: I tried to create a minimal example but couldn't isolate the problem. And since the code appears to compile and work fine, that's the reason why I asked about it here. – foraidt Feb 02 '11 at 09:54
  • @foraidt: Much better. :) Two things, though, the first is that, as the person asking the question, you're typically the least qualified to know what information is needed, because if you knew exactly what information was needed you'd solve it yourself. :) That said, secondly, it's not about "real code definitely makes a difference" but about "fake code could make a difference", and we want that to not be true. – GManNickG Feb 02 '11 at 09:55
  • @foraidt: The easiest way to go about this is just to take the .cpp file you are checking and remove all lines that are not needed to get the error. Then, go through all included .h files, remove all lines that do not cause the problem. Eventually you will have a very small collection of minimal .cpp and .h files. – Johan Kotlinski Feb 02 '11 at 09:59
-2

enums have data type as unsigned integers.

Update: Seems like it is implementation defined: Are C++ enums signed or unsigned?

Community
  • 1
  • 1
Arunmu
  • 6,837
  • 1
  • 24
  • 46
  • 2
    Not true: http://stackoverflow.com/questions/159034/are-c-enums-signed-or-unsigned – Johan Kotlinski Feb 02 '11 at 09:34
  • @Kotlinski : That is the link which I have pointed as an update on my answer. And a down vote and again pointing to the same link which I had given. The accepted answer clearly says :: "Also, the standard says that it is implementation-defined which integral type is used as the underlying type for an enum, except that it shall not be larger than int, unless some value cannot fit into int or an unsigned int." – Arunmu Feb 02 '11 at 10:39
  • @ArunMu: Posted the comment before I saw your update. Anyway, it does not really matter if underlying implementation is int or unsigned int unless you compare with < or >. – Johan Kotlinski Feb 02 '11 at 10:42
  • @Kotlinski:: How can you say that?? If the implementation goes with an unsigned int , do you think it will take a negative value as a negative value ? (unless for a casting ofcourse) – Arunmu Feb 02 '11 at 10:48
  • @ArunMu: `unsigned int i = -1;` will cast to `0xffffffffu`. At least on gcc this works fine, even with highest levels of warning. The representation is really the same... – Johan Kotlinski Feb 02 '11 at 10:56
  • @kotlinski : I really dont mind downvote :) but somehow i am not happy with the answers. – Arunmu Feb 02 '11 at 11:10
  • 2
    To quote: *"The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration"*. So the answer is not relevant and still starts with a wrong statement, thus the downvote. – Georg Fritzsche Feb 02 '11 at 11:32