Red Hat ENTERPRISE LINUX 4 Manual page 304

296
Shift count operands are probably signed more often than unsigned. Warning about this would cause
far more annoyance than good.
Warning about assigning a signed value to an unsigned variable.
•
Such assignments must be very common; warning about them would cause more annoyance than
good.
Warning when a non-void function value is ignored.
•
C contains many standard functions that return a value that most programs choose to ignore. One
obvious example is
clutter programs with dozens of casts to
come visual noise. Writing those casts becomes so automatic that they no longer convey useful
information about the intentions of the programmer. For functions where the return value should
never be ignored, use the
tributes of Functions).
Making
• -fshort-enums
This would cause storage layout to be incompatible with most other C compilers. And it doesn't
seem very important, given that you can get the same result in other ways. The case where it matters
most is when the enumeration-valued object is inside a structure, and in that case you can specify a
field width explicitly.
Making bit-fields unsigned by default on particular machines where "the ABI standard" says to do
•
so.
The ISO C standard leaves it up to the implementation whether a bit-field declared plain
signed or not. This in effect creates two alternative dialects of C.
The GNU C compiler supports both dialects; you can specify the signed dialect with
-fsigned-bitfields
leaves open the question of which dialect to use by default.
Currently, the preferred dialect makes plain bit-fields signed, because this is simplest. Since
the same as
signed int
as well.
Some computer manufacturers have published Application Binary Interface standards which spec-
ify that plain bit-fields should be unsigned. It is a mistake, however, to say anything about this issue
in an ABI. This is because the handling of plain bit-fields distinguishes two dialects of C. Both
dialects are meaningful on every type of machine. Whether a particular object file was compiled
using signed bit-fields or unsigned is of no concern to other object files, even if they access the
same bit-fields in the same data structures.
A given program is written in one or the other of these two dialects. The program stands a chance
to work on most any machine if it is compiled with the proper dialect. It is unlikely to work at all if
compiled with the wrong dialect.
Many users appreciate the GNU C compiler because it provides an environment that is uniform
across machines. These users would be inconvenienced if the compiler treated plain bit-fields dif-
ferently on certain machines.
Occasionally users write programs intended only for a particular machine type. On these occasions,
the users would benefit if the GNU C compiler were to support by default the same dialect as the
other compilers on that machine. But such applications are rare. And users writing a program to run
on more than one type of machine cannot possibly benefit from this kind of compatibility.
This is why GCC does and will treat plain bit-fields in the same fashion on all types of machines
(by default).
There are some arguments for making bit-fields unsigned by default on all machines. If, for exam-
ple, this becomes a universal de facto standard, it would make sense for GCC to go along with it.
This is something to be considered in the future.
. Warning about this practice only leads the defensive programmer to
printf
warn_unused_result
the default.
and the unsigned dialect with
in every other context, it is cleanest for them to be the same in bit-fields
Chapter 11. Known Causes of Trouble with GCC
. Such casts are required so frequently that they be-
void
function attribute (Section 6.25 Declaring At-
-funsigned-bitfields
is
int
. However, this
is
int