--- src/host/osmocon/osmocon.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index 5f28992..fc29506 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -123,6 +123,7 @@ enum dnload_mode { MODE_C155, MODE_ROMLOAD, MODE_MTK, + MODE_INVALID, };
struct dnload { @@ -1184,7 +1185,7 @@ static int parse_mode(const char *arg) else if (!strcasecmp(arg, "mtk")) return MODE_MTK;
- return -1; + return MODE_INVALID; }
#define HELP_TEXT \ @@ -1413,7 +1414,7 @@ int main(int argc, char **argv) break; case 'm': dnload.mode = parse_mode(optarg); - if (dnload.mode < 0) + if (dnload.mode == MODE_INVALID) usage(argv[0]); break; case 's':
Alexander Huemer wrote:
diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index 5f28992..fc29506 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -123,6 +123,7 @@ enum dnload_mode { MODE_C155, MODE_ROMLOAD, MODE_MTK,
- MODE_INVALID,
};
struct dnload { @@ -1184,7 +1185,7 @@ static int parse_mode(const char *arg) else if (!strcasecmp(arg, "mtk")) return MODE_MTK;
- return -1;
- return MODE_INVALID;
}
#define HELP_TEXT \ @@ -1413,7 +1414,7 @@ int main(int argc, char **argv) break; case 'm': dnload.mode = parse_mode(optarg);
if (dnload.mode < 0)
if (dnload.mode == MODE_INVALID) usage(argv[0]); break;
How was it incorrect before?
//Peter
How was it incorrect before?
According to specs, enum types _can_ be unsigned and so the test would be always false.
http://stackoverflow.com/questions/2579230/signedness-of-enum-in-c-c99-c-cx-...
Cheers,
Sylvain
How was it incorrect before?
According to specs, enum types _can_ be unsigned and so the test would be always false.
Ok. I thought perhaps the first enum was set to 0, which guarantees that all following enums are positive integers.
They are all positive integers ... And since the enum type in this case is unsigned, an unsigned value can never be inferior to 0 and so the test is always false.
Cheers,
Sylvain
Sylvain Munaut wrote:
How was it incorrect before?
According to specs, enum types _can_ be unsigned and so the test would be always false.
Ok. I thought perhaps the first enum was set to 0, which guarantees that all following enums are positive integers.
They are all positive integers ...
That's only certain if one enum value is defined to >= 0, and no later enum is defined to < 0. If no enum value is defined at all, then they may very well be negative.
And since the enum type in this case is unsigned, an unsigned value can never be inferior to 0 and so the test is always false.
enums don't have signedness AFAIU?
//Peter
That's only certain if one enum value is defined to >= 0, and no later enum is defined to < 0. If no enum value is defined at all, then they may very well be negative.
Well yes, I was talking about this particular case.
And since the enum type in this case is unsigned, an unsigned value can never be inferior to 0 and so the test is always false.
enums don't have signedness AFAIU?
They do (in the underlying type).
But it can be anything the compiler decides as long as it can fit all the enumeration constant and is no larger than int. And since in this case there is no negative constant (begin at 0 and go up), the compiler is free to decide to use "unsigned int" as underlying type. And gcc does that, yielding a bug in this case.
See the test case posted in IRC yesterday: http://pastebin.com/raw.php?i=cqi0ipY9
If you compile with -Wextra, you will see the issue.
Cheers,
Sylvain
That's only certain if one enum value is defined to >= 0, and no later enum is defined to < 0. If no enum value is defined at all, then they may very well be negative.
Oh, I actually mis-read this in my last answer.
I'm pretty sure that the first value defaults to 0 if not forced to another value.
Cheers,
Sylvain
Sylvain Munaut wrote:
That's only certain if one enum value is defined to >= 0, and no later enum is defined to < 0. If no enum value is defined at all, then they may very well be negative.
Oh, I actually mis-read this in my last answer.
I'm pretty sure that the first value defaults to 0 if not forced to another value.
I think not neccessarily so. If there is no specified value for any enum value then IIRC they are all undefined, and could thus also be negative. Bad.
//Peter
Hi,
I think not neccessarily so. If there is no specified value for any enum value then IIRC they are all undefined, and could thus also be negative. Bad.
The C99 standard clearly states ( 6.7.2.2 paragraph 3 )
"An enumerator with = defines its enumeration constant as the value of the constant expression. If the first enumerator has no =, the value of its enumeration constant is 0."
Cheers,
Sylvain
Hi!
Sylvain Munaut wrote:
I think not neccessarily so. If there is no specified value for any enum value then IIRC they are all undefined, and could thus also be negative. Bad.
The C99 standard clearly states ( 6.7.2.2 paragraph 3 )
"An enumerator with = defines its enumeration constant as the value of the constant expression. If the first enumerator has no =, the value of its enumeration constant is 0."
Ah good! I guess we only care about C99 compilers.
//Peter
baseband-devel@lists.osmocom.org
-
Alexander Huemer -
Peter Stuge -
Sylvain Munaut