We had a bug in our code coming from the line
unsigned int i = -1;
When the code was originally written, is was i = 0 and thus correct.
Using -Wall -Wextra, I was a bit surprised that gcc didn't warn me here because -1 does not fit in an unsigned int.
Only when turning on -Wsign-conversion this line becomes a warning - but with it many many false positives. I am using a third party library which does array-like operations with signed int's (although they cannot be < 0), so whenever I mix that with e.g. vector, I get warnings - and I don't see the point in adding millions of casts (and even the 3rd party headers produce a lot of warnings). So it is too many warnings for me. All these warnings are that the conversion "may change the sign". That's fine because I know it doesn't in almost all of the cases.
But with the assignment mentioned above, I get the same "may change" warning. Shouldn't this be "Will definitely change sign!" instead of "may change"? Is there any way to emit warnings only for these "will change" cases, not for the maybe cases?
Initialize it with curly braces :
unsigned int i{-1};
GCC outputs :
main.cpp:3:22: error: narrowing conversion of '-1'
from 'int' to 'unsigned int' inside { } [-Wnarrowing]
unsigned int i{-1};
Note that it does not always cause an error, it might be a warning or disabled altogether. You should try it with your actual toolchain.
But with the assignment mentioned above, I get the same "may change" warning. Shouldn't this be "Will definitely change sign!" instead of "may change"?
That's odd. I tested a few versions of gcc in the range of (4.6 - 5.2) and they did give a different warning for unsigned int i = -1;
warning: negative integer implicitly converted to unsigned type [-Wsign-conversion]
That said, they are indeed controlled by the same option as the may change sign warnings, so...
Is there any way to emit warnings only for these "will change" cases, not for the maybe cases?
As far as I know, that's not possible. I'm sure it would be possible to implement in the compiler, so if you want a separate option to enable the warning for assigning a negative number - known at compile time - to an unsigned variable, then you can submit a feature request. However, because assigning -1 to an unsigned variable is such a common and usually perfectly valid thing to do, I doubt such feature would be considered very important.
Related
At the advice of a high rep SO user, I've recently started compiling with the -Wconversion flag on my codebase. This has generated quite a few warnings, some which are legitimate (needlessly adding signed and unsigned types, for instance), but also some head scratchers, demonstrated below:
#include <cstdint>
int main()
{
uint16_t a = 4;
uint16_t b = 5;
b += a;
return 0;
}
When I compile with g++ -Wconversion -std=c++11 -O0 myFile.cpp, I get
warning: conversion to 'uint16_t {aka short unsigned int}' from 'int' may alter its value [-Wconversion]
b += a;
^
I've perused some similar questions on SO (dealing with | and << operators), taken a look here, and have read the Numeric Promotions and Numeric Conversions sections here. My understanding is, in order to do the math, a and b are promoted to int (since that's the first type that can fit the entire uint16_t value range), math is performed, the result is written back... except the result of the math is an int, and writing that back to uint16_t generates the warning. The consensus of the other questions was basically to cast away the warning, and the only way I've figured out how to do that is b = (uint16_t)(b + a); (or the equivalent b = static_cast<uint16_t>(b + a);).
Don't want this question to get too broad, but assuming my understanding of integer promotions is correct...
What's the best way to handle this moving forward? Should I avoid performing math on types narrower than int? It seems quite odd to me that I have to cast an arithmetic result which is the same type as all the operands (guess I would expect the compiler to recognize that and suppress the warning). Historically, I've liked to use no more bits than I need, and just let the compiler handle the promotions/conversions/padding as necessary.
Anyone use -Wconversion flag frequently? Just after a couple of days of using it myself, I'm starting to think its best use case is to turn it on, look at what it complains about, fix the legitimate complaints, then turn it back off. Or perhaps my definition of "legitimate complaint" needs readjusting. Replacing all of my += operators with spelled out casts seems like a nuisance more than anything.
I'm tempted to tag this as c as well, since an equivalent c code compiled with gcc -Wconversion -std=c11 -O0 myFile.c produces the exact same warning. But as is, I'm using g++ version 5.3.1 on an x86_64 Fedora 23 box. Please point me to the dupe if I've missed it; if the only answer/advice here is to cast away the warning, then this is a dupe.
What's the best way to handle this moving forward?
-Wno-conversion
Or just leave it unspecified. This is just an opinion, though.
In my experience, the need for narrow integer arithmetic tends to be quite rare, so you could still keep it on for the project, and disable for the few cases where this useless warning occurs. However, this probably depends highly on the type of your project, so your experience may vary.
Should I avoid performing math on types narrower than int?
Usually yes; unless you have a specific reason to use them. "I don't need the extra bits" isn't a specific enough reason in my opinion. Arithmetic operands are promoted to int anyway and it's usually faster and less error prone to use int.
Just after a couple of days of using it myself, I'm starting to think its best use case is to turn it on, look at what it complains about, fix the legitimate complaints, then turn it back off.
This is quite often a useful approach to warning flags that are included in neither -Wall nor -Wextra such as the ones with -Wsuggest- prefix. There is a reason why they aren't included in "all warnings".
I think this can be considered a shortcoming of gcc.
As this code doesn't generate any warning:
int a = ..., b = ...;
a += b;
This code should not generate either, because semantically they are the same (two same-type numbers are added, and the result is put into a same-type variable):
short a = ..., b = ...;
a += b;
But GCC generates a warning, because as you say, the short's gets promoted to int's. But the short version isn't more dangerous as the int one, in the sense that if the addition overflows, then the behavior is implementation-defined for the short case, and undefined for the int case (or if unsigned numbers are used, then truncation can happen in both cases).
Clang handles this case more intelligently, and doesn't warn for this case. I think it's because it actually tracks the possible bit-width (or maybe range?) of the result. So, for example, this warns:
int a = ...;
short b = a;
But this doesn't (but GCC warns for this):
int a = ...;
short b = a&0xf; // there is a conversion here, but clang knows that only 4 bits are used, so it doesn't warn
So, until GCC will have a more intelligent -Wconversion, your options are:
don't use -Wconversion
fix all the warnings it prints
use clang instead (maybe for GCC: turn off this warning; and for clang: turn it on)
But don't hold your breath until it's fixed, there is a bug about this, opened in 2009.
A note:
Historically, I've liked to use no more bits than I need, and just let the compiler handle the promotions/conversions/padding as necessary.
If you use shorter types for storage, it's fine. But usually, there's no reason to use shorter types than int for arithmetic. It gives no speedup (even, it can be slower, because of the unnecessary maskings).
Consider the following example:
unsigned short c = // ...
if (c > 0xfffful)
c = 0xfffful;
Since unsigned short can actually be larger than 16 bits, I want to limit the value before snprintf it in hex format to a fixed-size buffer.
However, GCC (but not clang) gives a warning: comparison is always false due to limited range of data type [-Wtype-limits].
Is it a bug in GCC or I missed something? I understand that on my machine unsigned short is exactly 16 bits, but it's not guaranteed to be so on other platforms.
I'd say it is not a bug. GCC is claiming if (c > 0xfffful) will always be false, which, on your machine, is true. GCC was smart enough to catch this, clang wasn't. Good job GCC!
On the other hand, GCC was not smart enough to notice that while it was always false on your machine, its not necessarily always false on someone else's machine. Come on GCC!
Note that in C++11, the *_least##_t types appear (I reserve the right to be proven wrong!) to be implemented by typedef. By the time GCC is running it's warning checks it likely has no clue that the original data type was uint_least16_t. If that is the case, the compiler would have no way of inferring that the comparison might be true on other systems. Changing GCC to remember what the original data type was might be extremely difficult. I'm not defending GCC's naive warning but suggesting why it might be hard to fix.
I'd be curious to see what the GCC guys say about this. Have you considered filing an issue with them?
This doesn't seem like a bug (maybe it could be deemed a slightly naive feature), but I can see why you'd want this code there for portability.
In the absence of any standard macros to tell you what the size of the type is on your platform (and there aren't any), I would probably have a step in my build process that works that out and passes it to your program as a -D definition.
e.g. in Make:
if ...
CFLAGS += -DTRUNCATE_UINT16_LEAST_T
endif
then:
#ifdef TRUNCATE_UINT16_LEAST_T
if (c > 0xfffful)
c = 0xfffful;
#endif
with the Makefile conditional predicated on output from a step in configure, or the execution of some other C++ program that simply prints out sizeofs. Sadly that rules out cross-compiling.
Longer-term I propose suggesting more intelligent behaviour to the GCC guys, for when these particular type aliases are in use.
i'm looking for the exact reason why does this conversion gives up a warning on c++ but not on c. does it connected to the fact that c++ is strongly type and c is weakly type ?
is it because the type in c can be determined while running so the compile does not points out a warning ?
thank you.
The presence or absence of a warning on a conversion from double to int has nothing to do with any difference between C and C++.
A warning (and you didn't tell us what the warning looks like; please update the question with that information) is probably valid. If the truncated double value is outside the representable range of int, the behavior is undefined. If it's within the range, but not mathematically equal to an integer, then the conversion will loose information.
Some compilers will warn about things like this, others won't -- and a given compiler may or may not issue a warning depending on what options you specify.
I have no idea why this code complies :
int array[100];
array[-50] = 100; // Crash!!
...the compiler still compiles properly, without compiling errors, and warnings.
So why does it compile at all?
array[-50] = 100;
Actually means here:
*(array - 50) = 100;
Take into consideration this code:
int array[100];
int *b = &(a[50]);
b[-20] = 5;
This code is valid and won't crash. Compiler has no way of knowing, whether the code will crash or not and what programmer wanted to do with the array. So it does not complain.
Finally, take into consideration, that you should not rely on compiler warnings while finding bugs in your code. Compilers will not find most of your bugs, they barely try to make some hints for you to ease the bugfixing process (sometimes they even may be mistaken and point out, that valid code is buggy). Also, the standard actually never requires the compiler to emit warning, so these are only an act of good will of compiler implementers.
It compiles because the expression array[-50] is transformed to the equivalent
*(&array[0] + (-50))
which is another way of saying "take the memory address &array[0] and add to it -50 times sizeof(array[0]), then interpret the contents of the resulting memory address and those following it as an int", as per the usual pointer arithmetic rules. This is a perfectly valid expression where -50 might really be any integer (and of course it doesn't need to be a compile-time constant).
Now it's definitely true that since here -50 is a compile-time constant, and since accessing the minus 50th element of an array is almost always an error, the compiler could (and perhaps should) produce a warning for this.
However, we should also consider that detecting this specific condition (statically indexing into an array with an apparently invalid index) is something that you don't expect to see in real code. Therefore the compiler team's resources will be probably put to better use doing something else.
Contrast this with other constructs like if (answer = 42) which you do expect to see in real code (if only because it's so easy to make that typo) and which are hard to debug (the eye can easily read = as ==, whereas that -50 immediately sticks out). In these cases a compiler warning is much more productive.
The compiler is not required to catch all potential problems at compile time. The C standard allows for undefined behavior at run time (which is what happens when this program is executed). You may treat it as a legal excuse not to catch this kind of bugs.
There are compilers and static program analyzers that can do catch trivial bugs like this, though.
True compilers do (note: need to switch the compiler to clang 3.2, gcc is not user-friendly)
Compilation finished with warnings:
source.cpp:3:4: warning: array index -50 is before the beginning of the array [-Warray-bounds]
array[-50] = 100;
^ ~~~
source.cpp:2:4: note: array 'array' declared here
int array[100];
^
1 warning generated.
If you have a lesser (*) compiler, you may have to setup the warning manually though.
(*) ie, less user-friendly
The number inside the brackets is just an index. It tells you how many steps in memory to take to find the number you're requesting. array[2] means start at the beginning of array, and jump forwards two times.
You just told it to jump backwards 50 times, which is a valid statement. However, I can't imagine there being a good reason for doing this...
My questions are divided into three parts
Question 1
Consider the below code,
#include <iostream>
using namespace std;
int main( int argc, char *argv[])
{
const int v = 50;
int i = 0X7FFFFFFF;
cout<<(i + v)<<endl;
if ( i + v < i )
{
cout<<"Number is negative"<<endl;
}
else
{
cout<<"Number is positive"<<endl;
}
return 0;
}
No specific compiler optimisation options are used or the O's flag is used. It is basic compilation command g++ -o test main.cpp is used to form the executable.
The seemingly very simple code, has odd behaviour in SUSE 64 bit OS, gcc version 4.1.2. The expected output is "Number is negative", instead only in SUSE 64 bit OS, the output would be "Number is positive".
After some amount of analysis and doing a 'disass' of the code, I find that the compiler optimises in the below format -
Since i is same on both sides of comparison, it cannot be changed in the same expression, remove 'i' from the equation.
Now, the comparison leads to if ( v < 0 ), where v is a constant positive, So during compilation itself, the else part cout function address is added to the register. No cmp/jmp instructions can be found.
I see that the behaviour is only in gcc 4.1.2 SUSE 10. When tried in AIX 5.1/5.3 and HP IA64, the result is as expected.
Is the above optimisation valid?
Or, is using the overflow mechanism for int not a valid use case?
Question 2
Now when I change the conditional statement from if (i + v < i) to if ( (i + v) < i ) even then, the behaviour is same, this atleast I would personally disagree, since additional braces are provided, I expect the compiler to create a temporary built-in type variable and them compare, thus nullify the optimisation.
Question 3
Suppose I have a huge code base, an I migrate my compiler version, such bug/optimisation can cause havoc in my system behaviour. Ofcourse from business perspective, it is very ineffective to test all lines of code again just because of compiler upgradation.
I think for all practical purpose, these kinds of error are very difficult to catch (during upgradation) and invariably will be leaked to production site.
Can anyone suggest any possible way to ensure to ensure that these kind of bug/optimization does not have any impact on my existing system/code base?
PS :
When the const for v is removed from the code, then optimization is not done by the compiler.
I believe, it is perfectly fine to use overflow mechanism to find if the variable is from MAX - 50 value (in my case).
Update(1)
What would I want to achieve? variable i would be a counter (kind of syncID). If I do offline operation (50 operation) then during startup, I would like to reset my counter, For this I am checking the boundary value (to reset it) rather than adding it blindly.
I am not sure if I am relying on the hardware implementation. I know that 0X7FFFFFFF is the max positive value. All I am doing is, by adding value to this, I am expecting the return value to be negative. I don't think this logic has anything to do with hardware implementation.
Anyways, all thanks for your input.
Update(2)
Most of the inpit states that I am relying on the lower level behavior on overflow checking. I have one questions regarding the same,
If that is the case, For an unsigned int how do I validate and reset the value during underflow or overflow? like if v=10, i=0X7FFFFFFE, I want reset i = 9. Similarly for underflow?
I would not be able to do that unless I check for negativity of the number. So my claim is that int must return a negative number when a value is added to the +MAX_INT.
Please let me know your inputs.
It's a known problem, and I don't think it's considered a bug in the compiler. When I compile with gcc 4.5 with -Wall -O2 it warns
warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false
Although your code does overflow.
You can pass the -fno-strict-overflow flag to turn that particular optimization off.
Your code produces undefined behavior. C and C++ languages has no "overflow mechanism" for signed integer arithmetic. Your calculations overflow signed integers - the behavior is immediately undefined. Considering it form "a bug in the compiler or not" position is no different that attempting to analyze the i = i++ + ++i examples.
GCC compiler has an optimization based on that part of the specification of C/C++ languages. It is called "strict overflow semantics" or something lake that. It is based on the fact that adding a positive value to a signed integer in C++ always produces a larger value or results in undefined behavior. This immediately means that the compiler is perfectly free to assume that the sum is always larger. The general nature of that optimization is very similar to the "strict aliasing" optimizations also present in GCC. They both resulted in some complaints from the more "hackerish" parts of GCC user community, many of whom didn't even suspect that the tricks they were relying on in their C/C++ programs were simply illegal hacks.
Q1: Perhaps, the number is indeed positive in a 64bit implementation? Who knows? Before debugging the code I'd just printf("%d", i+v);
Q2: The parentheses are only there to tell the compiler how to parse an expression. This is usually done in the form of a tree, so the optimizer does not see any parentheses at all. And it is free to transform the expression.
Q3: That's why, as c/c++ programmer, you must not write code that assumes particular properties of the underlying hardware, such as, for example, that an int is a 32 bit quantity in two's complement form.
What does the line:
cout<<(i + v)<<endl;
Output in the SUSE example? You're sure you don't have 64bit ints?
OK, so this was almost six years ago and the question is answered. Still I feel that there are some bits that have not been adressed to my satisfaction, so I add a few comments, hopefully for the good of future readers of this discussion. (Such as myself when I got a search hit for it.)
The OP specified using gcc 4.1.2 without any special flags. I assume the absence of the -O flag is equivalent to -O0. With no optimization requested, why did gcc optimize away code in the reported way? That does seem to me like a compiler bug. I also assume this has been fixed in later versions (for example, one answer mentions gcc 4.5 and the -fno-strict-overflow optimization flag). The current gcc man page states that -fstrict-overflow is included with -O2 or more.
In current versions of gcc, there is an option -fwrapv that enables you to use the sort of code that caused trouble for the OP. Provided of course that you make sure you know the bit sizes of your integer types. From gcc man page:
-fstrict-overflow
.....
See also the -fwrapv option. Using -fwrapv means that integer signed overflow
is fully defined: it wraps. ... With -fwrapv certain types of overflow are
permitted. For example, if the compiler gets an overflow when doing arithmetic
on constants, the overflowed value can still be used with -fwrapv, but not otherwise.