E.g.
long int a=1<<10;
The compiler won't warn that a and 1 are of different arithmetic types although I have verbose and warnings set to All
Different is not a warning. Truncation is.
The compiler will warn you if you are throwing away all your data by shifting an N-bit data type by N or more bits. It will also warn you if you are saving a value into a shorter data type. Other operations, such as shifting SOME of the bits off the end or moving to a LARGER data type are normal enough as to not require a warning.
void setup() {
Serial.begin(9600);
unsigned long al = 1 << 10;
unsigned long bl = 1 << 17; // Shift warning
unsigned long cl = 1UL << 17;
unsigned long dl = 1UL << 33; // Shift warning
unsigned a = 1 << 10;
unsigned b = 1 << 17; // Shift warning
unsigned c = 1UL << 17; // Implicit runcation warning
unsigned d = 1UL << 33; // Shift warning
Serial.println(al + bl + cl + dl);
Serial.println(a + b + c + d);
}
void loop() {
}
sketch_dec14a.ino: In function 'void setup()':
sketch_dec14a.ino:4:27: warning: left shift count >= width of type
unsigned long bl = 1 << 17; // Shift warning
^
sketch_dec14a.ino:6:29: warning: left shift count >= width of type
unsigned long dl = 1UL << 33; // Shift warning
^
sketch_dec14a.ino:8:22: warning: left shift count >= width of type
unsigned b = 1 << 17; // Shift warning
^
sketch_dec14a.ino:9:24: warning: large integer implicitly truncated to unsigned type [-Woverflow]
unsigned c = 1UL << 17; // Implicit runcation warning
^
sketch_dec14a.ino:10:24: warning: left shift count >= width of type
unsigned d = 1UL << 33; // Shift warning
^
The compiler won't warn that a and 1 are of different arithmetic types
But they are not different arithmetic types.
#define sp Serial.print
#define spln Serial.println
void setup() {
Serial.begin(115200);
while (!Serial);
long int a=0x80000;
long int mask;
for(int i=19;i>18;i--){
mask=1<<i;
sp("mask is ");sp(mask, BIN);sp(" masked a is "); spln(a&mask,BIN);
}
}
void loop() {
;
}
running this gives
mask is 0 masked a is 0
whereas with
mask=1L<<i;
we get
mask is 10000000000000000000 masked a is 10000000000000000000
For me, the compiler should have flagged the assignment of
long=short
as a warning
In this specific case it costed me quite a while to understand why the masked result was not that expected
For me, the compiler should have flagged the assignment of
long=short
as a warning
Why? The short easily fit in the long. There is NO problem with that assignment. If there is a problem, exactly what the problem is is a mystery, but it is NOT related to assigning a short to a long.
I should say that, in general, assigning a short to a long is not something that requires a warning. What isn't clear, to me, is what short you are talking about. 1<<n is not a short. Numeric literals are, unless you indicate otherwise, are interpreted as ints. In the 1<<i case, 1 is an int. You can make it a long, so shifting it 19 bits makes sense. 1L<<i is one way. (unsigned long)1<<i is another.
I should have been more precise: it is not the assignment per se it's any mixture of types.
For instance if you multiply in fortran a RAEL16 by a REAL8, it's all right! what you get is all future values would lose half the precision with all the consequences for the spacecraft and so the compiler should shout.
The case I just show here is another good example
a is long
1 is short
the problem is that with this mixture I got a zero result while I should have get a nonzero result so I lost much time I could have spared if the compiler had issued a warning
so I lost much time I could have spared if the compiler had issued a warning
All you've accomplished with this post is waste everybody else's time.
Assigning a short to a long is ALWAYS legal, and ALWAYS works. If you have some reason to believe otherwise, post the code that illustrates the problem, and we'll describe what assumptions you are making that are wrong, and why they are wrong.
guy_c:
In this specific case it costed me quite a while to understand why the masked result was not that expected
Well now you know.
Unfortunately, nobody here is in a position to be able to fix that, since it requires modifying the compiler.
since it requires modifying the compiler.
Or OP's expectations. I suspect that his/her expectations are wrong, though we have seen no real code that illustrates his/her expectations or any reality.
PaulS:
All you've accomplished with this post is waste everybody else's time.
I am sorry, this is not what I wanted. I'll stop here