gcc: Non-bugs
1
1 13.8 Certain Changes We Don't Want to Make
1 ==========================================
1
1 This section lists changes that people frequently request, but which we
1 do not make because we think GCC is better without them.
1
1 * Checking the number and type of arguments to a function which has
1 an old-fashioned definition and no prototype.
1
1 Such a feature would work only occasionally--only for calls that
1 appear in the same file as the called function, following the
1 definition. The only way to check all calls reliably is to add a
1 prototype for the function. But adding a prototype eliminates the
1 motivation for this feature. So the feature is not worthwhile.
1
1 * Warning about using an expression whose type is signed as a shift
1 count.
1
1 Shift count operands are probably signed more often than unsigned.
1 Warning about this would cause far more annoyance than good.
1
1 * Warning about assigning a signed value to an unsigned variable.
1
1 Such assignments must be very common; warning about them would
1 cause more annoyance than good.
1
1 * Warning when a non-void function value is ignored.
1
1 C contains many standard functions that return a value that most
1 programs choose to ignore. One obvious example is 'printf'.
1 Warning about this practice only leads the defensive programmer to
1 clutter programs with dozens of casts to 'void'. Such casts are
1 required so frequently that they become visual noise. Writing
1 those casts becomes so automatic that they no longer convey useful
1 information about the intentions of the programmer. For functions
1 where the return value should never be ignored, use the
11 'warn_unused_result' function attribute (⇒Function
Attributes).
1
1 * Making '-fshort-enums' the default.
1
1 This would cause storage layout to be incompatible with most other
1 C compilers. And it doesn't seem very important, given that you
1 can get the same result in other ways. The case where it matters
1 most is when the enumeration-valued object is inside a structure,
1 and in that case you can specify a field width explicitly.
1
1 * Making bit-fields unsigned by default on particular machines where
1 "the ABI standard" says to do so.
1
1 The ISO C standard leaves it up to the implementation whether a
1 bit-field declared plain 'int' is signed or not. This in effect
1 creates two alternative dialects of C.
1
1 The GNU C compiler supports both dialects; you can specify the
1 signed dialect with '-fsigned-bitfields' and the unsigned dialect
1 with '-funsigned-bitfields'. However, this leaves open the
1 question of which dialect to use by default.
1
1 Currently, the preferred dialect makes plain bit-fields signed,
1 because this is simplest. Since 'int' is the same as 'signed int'
1 in every other context, it is cleanest for them to be the same in
1 bit-fields as well.
1
1 Some computer manufacturers have published Application Binary
1 Interface standards which specify that plain bit-fields should be
1 unsigned. It is a mistake, however, to say anything about this
1 issue in an ABI. This is because the handling of plain bit-fields
1 distinguishes two dialects of C. Both dialects are meaningful on
1 every type of machine. Whether a particular object file was
1 compiled using signed bit-fields or unsigned is of no concern to
1 other object files, even if they access the same bit-fields in the
1 same data structures.
1
1 A given program is written in one or the other of these two
1 dialects. The program stands a chance to work on most any machine
1 if it is compiled with the proper dialect. It is unlikely to work
1 at all if compiled with the wrong dialect.
1
1 Many users appreciate the GNU C compiler because it provides an
1 environment that is uniform across machines. These users would be
1 inconvenienced if the compiler treated plain bit-fields differently
1 on certain machines.
1
1 Occasionally users write programs intended only for a particular
1 machine type. On these occasions, the users would benefit if the
1 GNU C compiler were to support by default the same dialect as the
1 other compilers on that machine. But such applications are rare.
1 And users writing a program to run on more than one type of machine
1 cannot possibly benefit from this kind of compatibility.
1
1 This is why GCC does and will treat plain bit-fields in the same
1 fashion on all types of machines (by default).
1
1 There are some arguments for making bit-fields unsigned by default
1 on all machines. If, for example, this becomes a universal de
1 facto standard, it would make sense for GCC to go along with it.
1 This is something to be considered in the future.
1
1 (Of course, users strongly concerned about portability should
1 indicate explicitly in each bit-field whether it is signed or not.
1 In this way, they write programs which have the same meaning in
1 both C dialects.)
1
1 * Undefining '__STDC__' when '-ansi' is not used.
1
1 Currently, GCC defines '__STDC__' unconditionally. This provides
1 good results in practice.
1
1 Programmers normally use conditionals on '__STDC__' to ask whether
1 it is safe to use certain features of ISO C, such as function
1 prototypes or ISO token concatenation. Since plain 'gcc' supports
1 all the features of ISO C, the correct answer to these questions is
1 "yes".
1
1 Some users try to use '__STDC__' to check for the availability of
1 certain library facilities. This is actually incorrect usage in an
1 ISO C program, because the ISO C standard says that a conforming
1 freestanding implementation should define '__STDC__' even though it
1 does not have the library facilities. 'gcc -ansi -pedantic' is a
1 conforming freestanding implementation, and it is therefore
1 required to define '__STDC__', even though it does not come with an
1 ISO C library.
1
1 Sometimes people say that defining '__STDC__' in a compiler that
1 does not completely conform to the ISO C standard somehow violates
1 the standard. This is illogical. The standard is a standard for
1 compilers that claim to support ISO C, such as 'gcc -ansi'--not for
1 other compilers such as plain 'gcc'. Whatever the ISO C standard
1 says is relevant to the design of plain 'gcc' without '-ansi' only
1 for pragmatic reasons, not as a requirement.
1
1 GCC normally defines '__STDC__' to be 1, and in addition defines
1 '__STRICT_ANSI__' if you specify the '-ansi' option, or a '-std'
1 option for strict conformance to some version of ISO C. On some
1 hosts, system include files use a different convention, where
1 '__STDC__' is normally 0, but is 1 if the user specifies strict
1 conformance to the C Standard. GCC follows the host convention
1 when processing system include files, but when processing user
1 files it follows the usual GNU C convention.
1
1 * Undefining '__STDC__' in C++.
1
1 Programs written to compile with C++-to-C translators get the value
1 of '__STDC__' that goes with the C compiler that is subsequently
1 used. These programs must test '__STDC__' to determine what kind
1 of C preprocessor that compiler uses: whether they should
1 concatenate tokens in the ISO C fashion or in the traditional
1 fashion.
1
1 These programs work properly with GNU C++ if '__STDC__' is defined.
1 They would not work otherwise.
1
1 In addition, many header files are written to provide prototypes in
1 ISO C but not in traditional C. Many of these header files can
1 work without change in C++ provided '__STDC__' is defined. If
1 '__STDC__' is not defined, they will all fail, and will all need to
1 be changed to test explicitly for C++ as well.
1
1 * Deleting "empty" loops.
1
1 Historically, GCC has not deleted "empty" loops under the
1 assumption that the most likely reason you would put one in a
1 program is to have a delay, so deleting them will not make real
1 programs run any faster.
1
1 However, the rationale here is that optimization of a nonempty loop
1 cannot produce an empty one. This held for carefully written C
1 compiled with less powerful optimizers but is not always the case
1 for carefully written C++ or with more powerful optimizers. Thus
1 GCC will remove operations from loops whenever it can determine
1 those operations are not externally visible (apart from the time
1 taken to execute them, of course). In case the loop can be proved
1 to be finite, GCC will also remove the loop itself.
1
1 Be aware of this when performing timing tests, for instance the
1 following loop can be completely removed, provided
1 'some_expression' can provably not change any global state.
1
1 {
1 int sum = 0;
1 int ix;
1
1 for (ix = 0; ix != 10000; ix++)
1 sum += some_expression;
1 }
1
1 Even though 'sum' is accumulated in the loop, no use is made of
1 that summation, so the accumulation can be removed.
1
1 * Making side effects happen in the same order as in some other
1 compiler.
1
1 It is never safe to depend on the order of evaluation of side
1 effects. For example, a function call like this may very well
1 behave differently from one compiler to another:
1
1 void func (int, int);
1
1 int i = 2;
1 func (i++, i++);
1
1 There is no guarantee (in either the C or the C++ standard language
1 definitions) that the increments will be evaluated in any
1 particular order. Either increment might happen first. 'func'
1 might get the arguments '2, 3', or it might get '3, 2', or even '2,
1 2'.
1
1 * Making certain warnings into errors by default.
1
1 Some ISO C testsuites report failure when the compiler does not
1 produce an error message for a certain program.
1
1 ISO C requires a "diagnostic" message for certain kinds of invalid
1 programs, but a warning is defined by GCC to count as a diagnostic.
1 If GCC produces a warning but not an error, that is correct ISO C
1 support. If testsuites call this "failure", they should be run
1 with the GCC option '-pedantic-errors', which will turn these
1 warnings into errors.
1