AVR Freaks

Also, I would like to see that warning relaxed when it comes to assigning integer expressions to 8-bit variables.

For instance,

generates that warning. That is completely useless and unnecessary.

I want warnings when I assign something that is too big to fit, unless I explicitly make it fit with a cast. I do not want to add casts in cases like the one above, and the warning is just noise in that situation.

That sort of noise renders the warning useless for me.

Why on Earth would I want to add that cast ? The compiler should see that the result of manipulating that constant at compile time is small enough to fit in 8 bits.

I want to be warned if I do something that may cause a problem. The above mentioned example code is never going to cause a problem.

After you told me that this warning exists, I enabled it for one of my smaller projects. That resulted in 59 useless warnings about Atmel compile-time constants that fit in 8 bits. If there was a problem in my code, it would drown in the noise.

Obfuscating my source code with unnecessary casts is not an option.

The fact that you don't see it - even when you ask what the community wants - just adds to the frustration. The lack of useful warnings in avrgcc is a disgrace.

Along similar lines, this code does not generate a warning:

However, this does:

It's ridiculous.

> The lack of common sense is sticking out like a sore thumb.

Shut up with that, please.

Compilers are stupid machines, which cannot employ something like
"common sense". If someone requests a 16-bit integer constant
by writing "~(1 << 7)", how on earth should the compiler notice
that the developer is actually not interested in its upper 8 bits?

If you don't like the way the C standard is written, then don't
use this language. Or, don't enable that warning.

> I've always thought that ALL warnings should be enabled by default

Then, just add -Wextra to the default set of warning options in Atmel
Studio ... Oh, while you are at it, please do also:

• remove the option to generate RJMP/RCALL instead of JMP/CALL alltogether; it's very dangerous to generate code that won't link;
  the correct way for this would be to add -mrelax to the linker's
  commandline (which is essentially a mandatory option for all
  devices larger than 128 KiB)

• completely remove the option -fpack-struct; it's a pointless option in AVR-GCC, as the AVR doesn't feature structure padding
  anyway

• disable -fshort-enums by default; it risks being API incompatible when linking with code that has not been compiled that way; the
  better way is to use __attribute__((packed)) on the respective
  enum declaration consistently throughout the project (header
  and source files)

Refer to the link of the first post

Alex

It's not rocket science. If I write

how can there be any doubt that I want to clear bit 2 in x and do nothing else (given that sizeof x <= sizeof(int)) ?

The general form " &= "
should not produce the complained of warning in any standard C environment.
The implied conversion will never result in a change of value.
'Tain't necessary for the compiler to divine intent.
'Twould make sense for " &= 0x0F12" to produce a different warning.

produces a warning.

If the "goal" of the compiler is to catch the high order bits of the constant being thrown away, it should do so even when assigning the result to an int. It doesn't:

After those two statements, i and c hold the same value. The most significant byte in i is zero and the compiler should know that at compile time. Yet only the assignment to c is reported as a problem.

In other words, the compiler is happy to throw away 8 non-zero bits without warning. However, it does complain about 8 bits known to be zero being thrown away.