]>
Commit | Line | Data |
---|---|---|
c63539ff ML |
1 | .. |
2 | Copyright 1988-2022 Free Software Foundation, Inc. | |
3 | This is part of the GCC manual. | |
4 | For copying conditions, see the copyright.rst file. | |
5 | ||
6 | .. _non-bugs: | |
7 | ||
8 | Certain Changes We Don't Want to Make | |
9 | ************************************* | |
10 | ||
11 | This section lists changes that people frequently request, but which | |
12 | we do not make because we think GCC is better without them. | |
13 | ||
14 | * Checking the number and type of arguments to a function which has an | |
15 | old-fashioned definition and no prototype. | |
16 | ||
17 | Such a feature would work only occasionally---only for calls that appear | |
18 | in the same file as the called function, following the definition. The | |
19 | only way to check all calls reliably is to add a prototype for the | |
20 | function. But adding a prototype eliminates the motivation for this | |
21 | feature. So the feature is not worthwhile. | |
22 | ||
23 | * Warning about using an expression whose type is signed as a shift count. | |
24 | ||
25 | Shift count operands are probably signed more often than unsigned. | |
26 | Warning about this would cause far more annoyance than good. | |
27 | ||
28 | * Warning about assigning a signed value to an unsigned variable. | |
29 | ||
30 | Such assignments must be very common; warning about them would cause | |
31 | more annoyance than good. | |
32 | ||
33 | * Warning when a non-void function value is ignored. | |
34 | ||
35 | C contains many standard functions that return a value that most | |
36 | programs choose to ignore. One obvious example is ``printf``. | |
37 | Warning about this practice only leads the defensive programmer to | |
38 | clutter programs with dozens of casts to ``void``. Such casts are | |
39 | required so frequently that they become visual noise. Writing those | |
40 | casts becomes so automatic that they no longer convey useful | |
41 | information about the intentions of the programmer. For functions | |
42 | where the return value should never be ignored, use the | |
43 | :fn-attr:`warn_unused_result` function attribute (see :ref:`function-attributes`). | |
44 | ||
45 | * | |
46 | .. index:: fshort-enums | |
47 | ||
48 | Making :option:`-fshort-enums` the default. | |
49 | ||
50 | This would cause storage layout to be incompatible with most other C | |
51 | compilers. And it doesn't seem very important, given that you can get | |
52 | the same result in other ways. The case where it matters most is when | |
53 | the enumeration-valued object is inside a structure, and in that case | |
54 | you can specify a field width explicitly. | |
55 | ||
56 | * Making bit-fields unsigned by default on particular machines where 'the | |
57 | ABI standard' says to do so. | |
58 | ||
59 | The ISO C standard leaves it up to the implementation whether a bit-field | |
60 | declared plain ``int`` is signed or not. This in effect creates two | |
61 | alternative dialects of C. | |
62 | ||
63 | .. index:: fsigned-bitfields, funsigned-bitfields | |
64 | ||
65 | The GNU C compiler supports both dialects; you can specify the signed | |
66 | dialect with :option:`-fsigned-bitfields` and the unsigned dialect with | |
67 | :option:`-funsigned-bitfields`. However, this leaves open the question of | |
68 | which dialect to use by default. | |
69 | ||
70 | Currently, the preferred dialect makes plain bit-fields signed, because | |
71 | this is simplest. Since ``int`` is the same as ``signed int`` in | |
72 | every other context, it is cleanest for them to be the same in bit-fields | |
73 | as well. | |
74 | ||
75 | Some computer manufacturers have published Application Binary Interface | |
76 | standards which specify that plain bit-fields should be unsigned. It is | |
77 | a mistake, however, to say anything about this issue in an ABI. This is | |
78 | because the handling of plain bit-fields distinguishes two dialects of C. | |
79 | Both dialects are meaningful on every type of machine. Whether a | |
80 | particular object file was compiled using signed bit-fields or unsigned | |
81 | is of no concern to other object files, even if they access the same | |
82 | bit-fields in the same data structures. | |
83 | ||
84 | A given program is written in one or the other of these two dialects. | |
85 | The program stands a chance to work on most any machine if it is | |
86 | compiled with the proper dialect. It is unlikely to work at all if | |
87 | compiled with the wrong dialect. | |
88 | ||
89 | Many users appreciate the GNU C compiler because it provides an | |
90 | environment that is uniform across machines. These users would be | |
91 | inconvenienced if the compiler treated plain bit-fields differently on | |
92 | certain machines. | |
93 | ||
94 | Occasionally users write programs intended only for a particular machine | |
95 | type. On these occasions, the users would benefit if the GNU C compiler | |
96 | were to support by default the same dialect as the other compilers on | |
97 | that machine. But such applications are rare. And users writing a | |
98 | program to run on more than one type of machine cannot possibly benefit | |
99 | from this kind of compatibility. | |
100 | ||
101 | This is why GCC does and will treat plain bit-fields in the same | |
102 | fashion on all types of machines (by default). | |
103 | ||
104 | There are some arguments for making bit-fields unsigned by default on all | |
105 | machines. If, for example, this becomes a universal de facto standard, | |
106 | it would make sense for GCC to go along with it. This is something | |
107 | to be considered in the future. | |
108 | ||
109 | (Of course, users strongly concerned about portability should indicate | |
110 | explicitly in each bit-field whether it is signed or not. In this way, | |
111 | they write programs which have the same meaning in both C dialects.) | |
112 | ||
113 | * | |
114 | .. index:: ansi, std | |
115 | ||
116 | Undefining ``__STDC__`` when :option:`-ansi` is not used. | |
117 | ||
118 | Currently, GCC defines ``__STDC__`` unconditionally. This provides | |
119 | good results in practice. | |
120 | ||
121 | Programmers normally use conditionals on ``__STDC__`` to ask whether | |
122 | it is safe to use certain features of ISO C, such as function | |
123 | prototypes or ISO token concatenation. Since plain :command:`gcc` supports | |
124 | all the features of ISO C, the correct answer to these questions is | |
125 | 'yes'. | |
126 | ||
127 | Some users try to use ``__STDC__`` to check for the availability of | |
128 | certain library facilities. This is actually incorrect usage in an ISO | |
129 | C program, because the ISO C standard says that a conforming | |
130 | freestanding implementation should define ``__STDC__`` even though it | |
131 | does not have the library facilities. :samp:`gcc -ansi -pedantic` is a | |
132 | conforming freestanding implementation, and it is therefore required to | |
133 | define ``__STDC__``, even though it does not come with an ISO C | |
134 | library. | |
135 | ||
136 | Sometimes people say that defining ``__STDC__`` in a compiler that | |
137 | does not completely conform to the ISO C standard somehow violates the | |
138 | standard. This is illogical. The standard is a standard for compilers | |
139 | that claim to support ISO C, such as :samp:`gcc -ansi`---not for other | |
140 | compilers such as plain :command:`gcc`. Whatever the ISO C standard says | |
141 | is relevant to the design of plain :command:`gcc` without :option:`-ansi` only | |
142 | for pragmatic reasons, not as a requirement. | |
143 | ||
144 | GCC normally defines ``__STDC__`` to be 1, and in addition | |
145 | defines ``__STRICT_ANSI__`` if you specify the :option:`-ansi` option, | |
146 | or a :option:`-std` option for strict conformance to some version of ISO C. | |
147 | On some hosts, system include files use a different convention, where | |
148 | ``__STDC__`` is normally 0, but is 1 if the user specifies strict | |
149 | conformance to the C Standard. GCC follows the host convention when | |
150 | processing system include files, but when processing user files it follows | |
151 | the usual GNU C convention. | |
152 | ||
153 | * Undefining ``__STDC__`` in C++. | |
154 | ||
155 | Programs written to compile with C++-to-C translators get the | |
156 | value of ``__STDC__`` that goes with the C compiler that is | |
157 | subsequently used. These programs must test ``__STDC__`` | |
158 | to determine what kind of C preprocessor that compiler uses: | |
159 | whether they should concatenate tokens in the ISO C fashion | |
160 | or in the traditional fashion. | |
161 | ||
162 | These programs work properly with GNU C++ if ``__STDC__`` is defined. | |
163 | They would not work otherwise. | |
164 | ||
165 | In addition, many header files are written to provide prototypes in ISO | |
166 | C but not in traditional C. Many of these header files can work without | |
167 | change in C++ provided ``__STDC__`` is defined. If ``__STDC__`` | |
168 | is not defined, they will all fail, and will all need to be changed to | |
169 | test explicitly for C++ as well. | |
170 | ||
171 | * Deleting 'empty' loops. | |
172 | ||
173 | Historically, GCC has not deleted 'empty' loops under the | |
174 | assumption that the most likely reason you would put one in a program is | |
175 | to have a delay, so deleting them will not make real programs run any | |
176 | faster. | |
177 | ||
178 | However, the rationale here is that optimization of a nonempty loop | |
179 | cannot produce an empty one. This held for carefully written C compiled | |
180 | with less powerful optimizers but is not always the case for carefully | |
181 | written C++ or with more powerful optimizers. | |
182 | Thus GCC will remove operations from loops whenever it can determine | |
183 | those operations are not externally visible (apart from the time taken | |
184 | to execute them, of course). In case the loop can be proved to be finite, | |
185 | GCC will also remove the loop itself. | |
186 | ||
187 | Be aware of this when performing timing tests, for instance the | |
188 | following loop can be completely removed, provided | |
189 | ``some_expression`` can provably not change any global state. | |
190 | ||
191 | .. code-block:: c++ | |
192 | ||
193 | { | |
194 | int sum = 0; | |
195 | int ix; | |
196 | ||
197 | for (ix = 0; ix != 10000; ix++) | |
198 | sum += some_expression; | |
199 | } | |
200 | ||
201 | Even though ``sum`` is accumulated in the loop, no use is made of | |
202 | that summation, so the accumulation can be removed. | |
203 | ||
204 | * Making side effects happen in the same order as in some other compiler. | |
205 | ||
206 | .. index:: side effects, order of evaluation, order of evaluation, side effects | |
207 | ||
208 | It is never safe to depend on the order of evaluation of side effects. | |
209 | For example, a function call like this may very well behave differently | |
210 | from one compiler to another: | |
211 | ||
212 | .. code-block:: c++ | |
213 | ||
214 | void func (int, int); | |
215 | ||
216 | int i = 2; | |
217 | func (i++, i++); | |
218 | ||
219 | There is no guarantee (in either the C or the C++ standard language | |
220 | definitions) that the increments will be evaluated in any particular | |
221 | order. Either increment might happen first. ``func`` might get the | |
222 | arguments :samp:`2, 3`, or it might get :samp:`3, 2`, or even :samp:`2, 2`. | |
223 | ||
224 | * Making certain warnings into errors by default. | |
225 | ||
226 | Some ISO C testsuites report failure when the compiler does not produce | |
227 | an error message for a certain program. | |
228 | ||
229 | .. index:: pedantic-errors | |
230 | ||
231 | ISO C requires a 'diagnostic' message for certain kinds of invalid | |
232 | programs, but a warning is defined by GCC to count as a diagnostic. If | |
233 | GCC produces a warning but not an error, that is correct ISO C support. | |
234 | If testsuites call this 'failure', they should be run with the GCC | |
235 | option :option:`-pedantic-errors`, which will turn these warnings into | |
3ed1b4ce | 236 | errors. |