Next:Warning Messages and Error Messages, Previous:Common Misunderstandings with GNU C++, Up:Known Causes of Trouble with GCC [Contents][Index]
This section lists changes that people frequently request, but whichwe do not make because we think GCC is better without them.
Such a feature would work only occasionally—only for calls that appearin the same file as the called function, following the definition. Theonly way to check all calls reliably is to add a prototype for thefunction. But adding a prototype eliminates the motivation for thisfeature. So the feature is not worthwhile.
Shift count operands are probably signed more often than unsigned.Warning about this would cause far more annoyance than good.
Such assignments must be very common; warning about them would causemore annoyance than good.
C contains many standard functions that return a value that mostprograms choose to ignore. One obvious example isprintf.Warning about this practice only leads the defensive programmer toclutter programs with dozens of casts tovoid. Such casts arerequired so frequently that they become visual noise. Writing thosecasts becomes so automatic that they no longer convey usefulinformation about the intentions of the programmer. For functionswhere the return value should never be ignored, use thewarn_unused_result function attribute (seeDeclaring Attributes of Functions).
This would cause storage layout to be incompatible with most other Ccompilers. And it doesn’t seem very important, given that you can getthe same result in other ways. The case where it matters most is whenthe enumeration-valued object is inside a structure, and in that caseyou can specify a field width explicitly.
The ISO C standard leaves it up to the implementation whether a bit-fielddeclared plainint is signed or not. This in effect creates twoalternative dialects of C.
The GNU C compiler supports both dialects; you can specify the signeddialect with-fsigned-bitfields and the unsigned dialect with-funsigned-bitfields. However, this leaves open the question ofwhich dialect to use by default.
Currently, the preferred dialect makes plain bit-fields signed, becausethis is simplest. Sinceint is the same assigned int inevery other context, it is cleanest for them to be the same in bit-fieldsas well.
Some computer manufacturers have published Application Binary Interfacestandards which specify that plain bit-fields should be unsigned. It isa mistake, however, to say anything about this issue in an ABI. This isbecause the handling of plain bit-fields distinguishes two dialects of C.Both dialects are meaningful on every type of machine. Whether aparticular object file was compiled using signed bit-fields or unsignedis of no concern to other object files, even if they access the samebit-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 iscompiled with the proper dialect. It is unlikely to work at all ifcompiled with the wrong dialect.
Many users appreciate the GNU C compiler because it provides anenvironment that is uniform across machines. These users would beinconvenienced if the compiler treated plain bit-fields differently oncertain machines.
Occasionally users write programs intended only for a particular machinetype. On these occasions, the users would benefit if the GNU C compilerwere to support by default the same dialect as the other compilers onthat machine. But such applications are rare. And users writing aprogram to run on more than one type of machine cannot possibly benefitfrom this kind of compatibility.
This is why GCC does and will treat plain bit-fields in the samefashion on all types of machines (by default).
There are some arguments for making bit-fields unsigned by default on allmachines. If, for example, this becomes a universal de facto standard,it would make sense for GCC to go along with it. This is somethingto be considered in the future.
(Of course, users strongly concerned about portability should indicateexplicitly in each bit-field whether it is signed or not. In this way,they write programs which have the same meaning in both C dialects.)
__STDC__ when-ansi is not used.Currently, GCC defines__STDC__ unconditionally. This providesgood results in practice.
Programmers normally use conditionals on__STDC__ to ask whetherit is safe to use certain features of ISO C, such as functionprototypes or ISO token concatenation. Since plaingcc supportsall the features of ISO C, the correct answer to these questions is“yes”.
Some users try to use__STDC__ to check for the availability ofcertain library facilities. This is actually incorrect usage in an ISOC program, because the ISO C standard says that a conformingfreestanding implementation should define__STDC__ even though itdoes not have the library facilities. ‘gcc -ansi -pedantic’ is aconforming freestanding implementation, and it is therefore required todefine__STDC__, even though it does not come with an ISO Clibrary.
Sometimes people say that defining__STDC__ in a compiler thatdoes not completely conform to the ISO C standard somehow violates thestandard. This is illogical. The standard is a standard for compilersthat claim to support ISO C, such as ‘gcc -ansi’—not for othercompilers such as plaingcc. Whatever the ISO C standard saysis relevant to the design of plaingcc without-ansi onlyfor pragmatic reasons, not as a requirement.
GCC normally defines__STDC__ to be 1, and in additiondefines__STRICT_ANSI__ if you specify the-ansi option,or a-std option for strict conformance to some version of ISO C.On some hosts, system include files use a different convention, where__STDC__ is normally 0, but is 1 if the user specifies strictconformance to the C Standard. GCC follows the host convention whenprocessing system include files, but when processing user files it followsthe usual GNU C convention.
__STDC__ in C++.Programs written to compile with C++-to-C translators get thevalue of__STDC__ that goes with the C compiler that issubsequently used. These programs must test__STDC__to determine what kind of C preprocessor that compiler uses:whether they should concatenate tokens in the ISO C fashionor in the traditional fashion.
These programs work properly with GNU C++ if__STDC__ is defined.They would not work otherwise.
In addition, many header files are written to provide prototypes in ISOC but not in traditional C. Many of these header files can work withoutchange in C++ provided__STDC__ is defined. If__STDC__is not defined, they will all fail, and will all need to be changed totest explicitly for C++ as well.
Historically, GCC has not deleted “empty” loops under theassumption that the most likely reason you would put one in a program isto have a delay, so deleting them will not make real programs run anyfaster.
However, the rationale here is that optimization of a nonempty loopcannot produce an empty one. This held for carefully written C compiledwith less powerful optimizers but is not always the case for carefullywritten C++ or with more powerful optimizers.Thus GCC will remove operations from loops whenever it can determinethose operations are not externally visible (apart from the time takento execute them, of course). In case the loop can be proved to be finite,GCC will also remove the loop itself.
Be aware of this when performing timing tests, for instance thefollowing loop can be completely removed, providedsome_expression can provably not change any global state.
{ int sum = 0; int ix; for (ix = 0; ix != 10000; ix++) sum += some_expression;}Even thoughsum is accumulated in the loop, no use is made ofthat summation, so the accumulation can be removed.
It is never safe to depend on the order of evaluation of side effects.For example, a function call like this may very well behave differentlyfrom one compiler to another:
void func (int, int);int i = 2;func (i++, i++);
There is no guarantee (in either the C or the C++ standard languagedefinitions) that the increments will be evaluated in any particularorder. Either increment might happen first.func might get thearguments ‘2, 3’, or it might get ‘3, 2’, or even ‘2, 2’.
Some ISO C testsuites report failure when the compiler does not producean error message for a certain program.
ISO C requires a “diagnostic” message for certain kinds of invalidprograms, but a warning is defined by GCC to count as a diagnostic. IfGCC produces a warning but not an error, that is correct ISO C support.If testsuites call this “failure”, they should be run with the GCCoption-pedantic-errors, which will turn these warnings intoerrors.
Next:Warning Messages and Error Messages, Previous:Common Misunderstandings with GNU C++, Up:Known Causes of Trouble with GCC [Contents][Index]