From 754bbf7a25a8dda49b5d08ef0d0443bbf5af0e36 Mon Sep 17 00:00:00 2001
From: Craig Jennings <c@cjennings.net>
Date: Sun, 7 Apr 2024 13:41:34 -0500
Subject: new repository

---
 devdocs/gcc~13/non-bugs.html | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 devdocs/gcc~13/non-bugs.html

(limited to 'devdocs/gcc~13/non-bugs.html')

diff --git a/devdocs/gcc~13/non-bugs.html b/devdocs/gcc~13/non-bugs.html
new file mode 100644
index 00000000..02b45973
--- /dev/null
+++ b/devdocs/gcc~13/non-bugs.html
@@ -0,0 +1,30 @@
+<div class="section-level-extent" id="Non-bugs"> <div class="nav-panel"> <p> Next: <a href="warnings-and-errors" accesskey="n" rel="next">Warning Messages and Error Messages</a>, Previous: <a href="c_002b_002b-misunderstandings" accesskey="p" rel="prev">Common Misunderstandings with GNU C++</a>, Up: <a href="trouble" accesskey="u" rel="up">Known Causes of Trouble with GCC</a> [<a href="index#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="indices" title="Index" rel="index">Index</a>]</p> </div>  <h1 class="section" id="Certain-Changes-We-Don_0027t-Want-to-Make"><span>14.8 Certain Changes We Don’t Want to Make<a class="copiable-link" href="#Certain-Changes-We-Don_0027t-Want-to-Make"> ¶</a></span></h1> <p>This section lists changes that people frequently request, but which we do not make because we think GCC is better without them. </p> <ul class="itemize mark-bullet"> <li>Checking the number and type of arguments to a function which has an old-fashioned definition and no prototype. <p>Such a feature would work only occasionally—only for calls that appear in the same file as the called function, following the definition. The only way to check all calls reliably is to add a prototype for the function. But adding a prototype eliminates the motivation for this feature. So the feature is not worthwhile. </p> </li>
+<li>Warning about using an expression whose type is signed as a shift count. <p>Shift count operands are probably signed more often than unsigned. Warning about this would cause far more annoyance than good. </p> </li>
+<li>Warning about assigning a signed value to an unsigned variable. <p>Such assignments must be very common; warning about them would cause more annoyance than good. </p> </li>
+<li>Warning when a non-void function value is ignored. <p>C contains many standard functions that return a value that most programs choose to ignore. One obvious example is <code class="code">printf</code>. Warning about this practice only leads the defensive programmer to clutter programs with dozens of casts to <code class="code">void</code>. Such casts are required so frequently that they become 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 <code class="code">warn_unused_result</code> function attribute (see <a class="pxref" href="function-attributes">Declaring Attributes of Functions</a>). </p> </li>
+<li>
+ Making <samp class="option">-fshort-enums</samp> the default. <p>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. </p> </li>
+<li>Making bit-fields unsigned by default on particular machines where “the ABI standard” says to do so. <p>The ISO C standard leaves it up to the implementation whether a bit-field declared plain <code class="code">int</code> is signed or not. This in effect creates two alternative dialects of C. </p>   <p>The GNU C compiler supports both dialects; you can specify the signed dialect with <samp class="option">-fsigned-bitfields</samp> and the unsigned dialect with <samp class="option">-funsigned-bitfields</samp>. However, this leaves open the question of which dialect to use by default. </p> <p>Currently, the preferred dialect makes plain bit-fields signed, because this is simplest. Since <code class="code">int</code> is the same as <code class="code">signed int</code> in every other context, it is cleanest for them to be the same in bit-fields as well. </p> <p>Some computer manufacturers have published Application Binary Interface standards which specify 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. </p> <p>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. </p> <p>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 differently on certain machines. </p> <p>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. </p> <p>This is why GCC does and will treat plain bit-fields in the same fashion on all types of machines (by default). </p> <p>There are some arguments for making bit-fields unsigned by default on all machines. If, for example, 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. </p> <p>(Of course, users strongly concerned about portability should indicate explicitly 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.) </p> </li>
+<li>
+  Undefining <code class="code">__STDC__</code> when <samp class="option">-ansi</samp> is not used. <p>Currently, GCC defines <code class="code">__STDC__</code> unconditionally. This provides good results in practice. </p> <p>Programmers normally use conditionals on <code class="code">__STDC__</code> to ask whether it is safe to use certain features of ISO C, such as function prototypes or ISO token concatenation. Since plain <code class="command">gcc</code> supports all the features of ISO C, the correct answer to these questions is “yes”. </p> <p>Some users try to use <code class="code">__STDC__</code> to check for the availability of certain library facilities. This is actually incorrect usage in an ISO C program, because the ISO C standard says that a conforming freestanding implementation should define <code class="code">__STDC__</code> even though it does not have the library facilities. ‘<samp class="samp">gcc -ansi -pedantic</samp>’ is a conforming freestanding implementation, and it is therefore required to define <code class="code">__STDC__</code>, even though it does not come with an ISO C library. </p> <p>Sometimes people say that defining <code class="code">__STDC__</code> in a compiler that does not completely conform to the ISO C standard somehow violates the standard. This is illogical. The standard is a standard for compilers that claim to support ISO C, such as ‘<samp class="samp">gcc -ansi</samp>’—not for other compilers such as plain <code class="command">gcc</code>. Whatever the ISO C standard says is relevant to the design of plain <code class="command">gcc</code> without <samp class="option">-ansi</samp> only for pragmatic reasons, not as a requirement. </p> <p>GCC normally defines <code class="code">__STDC__</code> to be 1, and in addition defines <code class="code">__STRICT_ANSI__</code> if you specify the <samp class="option">-ansi</samp> option, or a <samp class="option">-std</samp> option for strict conformance to some version of ISO C. On some hosts, system include files use a different convention, where <code class="code">__STDC__</code> is normally 0, but is 1 if the user specifies strict conformance to the C Standard. GCC follows the host convention when processing system include files, but when processing user files it follows the usual GNU C convention. </p> </li>
+<li>Undefining <code class="code">__STDC__</code> in C++. <p>Programs written to compile with C++-to-C translators get the value of <code class="code">__STDC__</code> that goes with the C compiler that is subsequently used. These programs must test <code class="code">__STDC__</code> to determine what kind of C preprocessor that compiler uses: whether they should concatenate tokens in the ISO C fashion or in the traditional fashion. </p> <p>These programs work properly with GNU C++ if <code class="code">__STDC__</code> is defined. They would not work otherwise. </p> <p>In addition, many header files are written to provide prototypes in ISO C but not in traditional C. Many of these header files can work without change in C++ provided <code class="code">__STDC__</code> is defined. If <code class="code">__STDC__</code> is not defined, they will all fail, and will all need to be changed to test explicitly for C++ as well. </p> </li>
+<li>Deleting “empty” loops. <p>Historically, GCC has not deleted “empty” loops under the assumption that the most likely reason you would put one in a program is to have a delay, so deleting them will not make real programs run any faster. </p> <p>However, the rationale here is that optimization of a nonempty loop cannot produce an empty one. This held for carefully written C compiled with less powerful optimizers but is not always the case for carefully written C++ or with more powerful optimizers. Thus GCC will remove operations from loops whenever it can determine those operations are not externally visible (apart from the time taken to execute them, of course). In case the loop can be proved to be finite, GCC will also remove the loop itself. </p> <p>Be aware of this when performing timing tests, for instance the following loop can be completely removed, provided <code class="code">some_expression</code> can provably not change any global state. </p> <div class="example smallexample"> <pre class="example-preformatted" data-language="cpp">{
+   int sum = 0;
+   int ix;
+
+   for (ix = 0; ix != 10000; ix++)
+      sum += some_expression;
+}</pre>
+</div> <p>Even though <code class="code">sum</code> is accumulated in the loop, no use is made of that summation, so the accumulation can be removed. </p> </li>
+<li>Making side effects happen in the same order as in some other compiler.   <p>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 differently from one compiler to another: </p> <div class="example smallexample"> <pre class="example-preformatted" data-language="cpp">void func (int, int);
+
+int i = 2;
+func (i++, i++);</pre>
+</div> <p>There is no guarantee (in either the C or the C++ standard language definitions) that the increments will be evaluated in any particular order. Either increment might happen first. <code class="code">func</code> might get the arguments ‘<samp class="samp">2, 3</samp>’, or it might get ‘<samp class="samp">3, 2</samp>’, or even ‘<samp class="samp">2, 2</samp>’. </p> </li>
+<li>Making certain warnings into errors by default. <p>Some ISO C testsuites report failure when the compiler does not produce an error message for a certain program. </p>  <p>ISO C requires a “diagnostic” message for certain kinds of invalid programs, but a warning is defined by GCC to count as a diagnostic. If GCC produces a warning but not an error, that is correct ISO C support. If testsuites call this “failure”, they should be run with the GCC option <samp class="option">-pedantic-errors</samp>, which will turn these warnings into errors. </p> </li>
+</ul> </div>  <div class="nav-panel"> <p> Next: <a href="warnings-and-errors">Warning Messages and Error Messages</a>, Previous: <a href="c_002b_002b-misunderstandings">Common Misunderstandings with GNU C++</a>, Up: <a href="trouble">Known Causes of Trouble with GCC</a> [<a href="index#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="indices" title="Index" rel="index">Index</a>]</p> </div><div class="_attribution">
+  <p class="_attribution-p">
+    &copy; Free Software Foundation<br>Licensed under the GNU Free Documentation License, Version 1.3.<br>
+    <a href="https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Non-bugs.html" class="_attribution-link">https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Non-bugs.html</a>
+  </p>
+</div>
-- 
cgit v1.2.3