This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: faq.html, bugs.html
- To: Rich Churcher <churcher at ihug dot com dot au>
- Subject: Re: PATCH: faq.html, bugs.html
- From: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Date: Sun, 8 Jul 2001 15:04:40 +0200 (CEST)
- cc: <gcc-patches at gcc dot gnu dot org>
On 6 Jul 2001, Rich Churcher wrote:
> No, I mean making the output clearer. I was just thinking of adding
> some whitespace and emphasising the points a bit, but really it's so
> trivial I wouldn't even mention it if I weren't patching the file
> already.
Convinced. I kept your changes but used <em> for emphasising instead of
<i> (which is physical markup).
> The file is getting rather large. I've found it difficult to separate
> the patches I was going to submit.
Yes, the bugs.html patch alone took the equivalent of 8 tightly printed
pages of A4 paper. :-o
> Please feel free to ask me to resubmit if you're not happy with the
> way it looks. I just couldn't find an easy way to separate the changes
> out.
Overall, for the two of us, it was less work to make changes by myself, so
I did it that way. Let's try to keep patches a bit smaller though. ;-)
> 2001-07-05 Rich Churcher <churcher@ihug.com.au>
>
> * Add paragraph on lack of export keyword.
> * Markup changes to make reading definition lists slightly easier.
> * Add table of contents entries.
> * Transplant FAQ questions into Non-bugs section.
> * Created a "C" section to accomodate some FAQ questions.
>
>
> [faq-patch]
> 2001-07-05 Rich Churcher <churcher@ihug.com.au>
>
> * Remove "Bugs and Non-bugs" section - now in bugs.html
Thanks, I just installed these patches with minor tweaks. Below is
what I actually installed.
> Oh, BTW - do you prefer to be Cc'd when the message contains
> attachments, or not?
Personally, I do prefer attachments over (large) patches in the regular
body of e-mails, though it's usually better to avoid compressing them.
Cc:s on relevant messages are fine, even if I hope not to miss them on
the mailing lists, either. :)
Gerald
Index: bugs.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs.html,v
retrieving revision 1.31
diff -u -3 -p -r1.31 bugs.html
--- bugs.html 2001/06/18 09:33:13 1.31
+++ bugs.html 2001/07/08 12:55:53
@@ -5,26 +5,55 @@
</head>
<body>
+<h1 align="center">GCC Bugs</h1>
<p>The latest version of this document is always available at
-<a href="http://gcc.gnu.org/bugs.html";>http://gcc.gnu.org/bugs.html</a>.
+<a href="http://gcc.gnu.org/bugs.html";>
+http://gcc.gnu.org/bugs.html</a>.</p>
-<p><a href="#report">Reporting Bugs</a>
- | <a href="#manage">Managing Bugs (GNATS and the test-suite)</a>
- | <a href="#known">Frequently Reported Bugs in GCC 3.0</a>
-</p>
+<hr>
+<h2>Table of Contents</h2>
+<ul>
+<li><a href="#report">Reporting Bugs</a></li>
+ <ul>
+ <li><a href="#need">What we need</a></li>
+ <li><a href="#dontwant">What we DON'T want</a></li>
+ <li><a href="#where">Where to post it</a></li>
+ <li><a href="#detailed">Detailed bug reporting instructions</a></li>
+ </ul>
+<li><a href="#manage">Managing Bugs (GNATS and the test-suite)</a></li>
+<li><a href="#known">Frequently Reported Bugs in GCC 3.0</a></li>
+ <ul>
+ <li><a href="#general">General</a></li>
+ <li><a href="#fortran">Fortran</a></li>
+ <li><a href="#c">C</a></li>
+ <li><a href="#cplusplus">C++</a></li>
+ <ul>
+ <li><a href="#updating">Common problems updating from G++ 2.95 to
+ G++ 3.0</a></li>
+ <li><a href="#nonbugs">Non-bugs</a></li>
+ <li><a href="#missing">Missing features</a></li>
+ <li><a href="#parsing">Parse errors for "simple" code</a></li>
+ <li><a href="#-O3">Optimization at <code>-O3</code> takes a
+ very long time</a></li>
+ </ul>
+ </ul>
+</ul>
+
+<hr>
+
<h1><a name="report">Reporting Bugs</a></h1>
-<p>Our preferred way of receiving bugs is via our <a href="gnats.html">GNATS
-bug reporting system</a>.</p>
+<p>Our preferred way of receiving bugs is via our
+<a href="gnats.html">GNATS bug reporting system</a>.</p>
-<p>Before you report a bug, please check the <a href="#known">list of
-well-known bugs</a> and, <strong>if possible in any way, try a current
-development snapshot
-or <a href="http://www.codesourcery.com/gcc-compile.shtml";>CodeSourcery's
-Online Test Compilation</a></strong>. If you want to report a
-bug with egcs 1.x or versions of GCC before 3.0 we strongly recommend
+<p>Before you report a bug, please check the
+<a href="#known">list of well-known bugs</a> and, <strong>if possible
+in any way, try a current development snapshot or
+<a href="http://www.codesourcery.com/gcc-compile.shtml";>CodeSourcery's
+Online Test Compilation</a></strong>. If you want to report a bug
+with egcs 1.x or versions of GCC before 3.0 we strongly recommend
upgrading to the current release first.</p>
<p>Before reporting that GCC compiles your code incorrectly, please
@@ -38,7 +67,7 @@ in GCC.</p>
instructions, that explain how to obtain some of the information
requested in this summary.</p>
-<h3>What we need</h3>
+<h3><a name="need">What we need</a></h3>
Please include in your bug report <b>all</b> of the following items:
@@ -54,7 +83,7 @@ Please include in your bug report <b>all
<li>The options given when GCC was configured/built</li>
</ul>
-<h3>What we DON'T want</h3>
+<h3><a name="dontwant">What we DON'T want</a></h3>
<ul>
<li>A source file that <tt>#include</tt>s header files that are left
@@ -105,7 +134,7 @@ Please include in your bug report <b>all
dedicated to the discussion of the programming language</li>
</ul>
-<h3>Where to post it</h3>
+<h3><a name="where">Where to post it</a></h3>
<p>Please submit your bug report directly to our
<a href="gnats.html">GNATS</a> bug database. If this is not possible,
@@ -113,18 +142,19 @@ please mail all information to
<href="mailto:gcc-bugs@gcc.gnu.org";>gcc-bugs@gcc.gnu.org</a>.
-<h2>Detailed bug reporting instructions</h2>
+<h2><a name="detailed">Detailed bug reporting instructions</a></h2>
<p>In general, all the information we need can be obtained by
collecting the command line below, as well as its output and the
-preprocessed file it generates.</p>
+preprocessed file it generates.
-<p><tt>gcc -v -save-temps <i>all-your-options source-file</i></tt></p>
+<blockquote><code>gcc -v -save-temps <i>all-your-options
+source-file</i></code></blockquote>
-<p>Typically the preprocessed file (extension <code>.i</code> for C or
+Typically the preprocessed file (extension <code>.i</code> for C or
<code>.ii</code> for C++) will be large, so please compress the
resulting file with one of the popular compression programs such as
-<tt>bzip2</tt>, <tt>gzip</tt>, <tt>zip</tt> or <tt>compress</tt> (in
+bzip2, gzip, zip or compress (in
decreasing order of preference). Use maximum compression
(<code>-9</code>) if available. <b>Please</b> include the compressed
preprocessor output in your bug report, even if the source code is
@@ -199,10 +229,11 @@ contributors.</p>
<li>Check in your fixes.</li>
</ol>
+<hr>
<h1><a name="known">Frequently Reported Bugs in GCC 3.0</a></h1>
-<h2>General</h2>
+<h2><a name="general">General</a></h2>
<p>The following bugs are very frequently reported.</p>
@@ -210,21 +241,141 @@ contributors.</p>
<li>GCC 2.95.2 does not build on GNU/Linux systems using glibc 2.2,
such as Red Hat 7.0. A <a href="install/glibc-2.2.patch">patch</a> is
-available. This will be fixed in GCC 2.95.3 and GCC 3.0.</li>
+available. This is fixed in GCC 2.95.3 and GCC 3.0.</li>
<li>GCC 2.95.2 crashes when compiling <code>mbx.c</code> from the PINE
4.30 or IMAP2000 distribution on Sparc systems running Solaris.</li>
</ul>
+
+<hr>
+
+<h2><a name="fortran">Fortran</a></h2>
+
+<p> Fortran bugs are documented in the G77 manual rather than
+explicitly listed here. Please see
+<a href="onlinedocs/g77_bugs.html">"Known Causes of Trouble with GNU
+Fortran"</a> in the <a href="onlinedocs/g77_toc.html">G77 manual.</a>
+
+<hr>
+
+<h2><a name="c">C</a></h2>
+
+<p>The following are not bugs in the C compiler, but are reported
+often enough to warrant a mention here.</p>
+
+<dl>
+<dt><em>Cannot initialize a static variable with
+<code>stdin</code>.</em></dt>
+<dd><p>This has nothing to do with GCC, but people ask us about it a
+lot. Code like this:
+
+<blockquote><code>
+ #include <stdio.h>
+
+ FILE *yyin = stdin;
+</code></blockquote>
+
+will not compile with GNU libc (GNU/Linux libc6), because
+<code>stdin</code> is not a constant. This was done deliberately, in
+order for there to be no limit on the number of open <code>FILE</code>
+objects. It is surprising for people used to traditional Unix C
+libraries, but it is permitted by the C standard.</p>
+
+<p>This construct commonly occurs in code generated by old versions of
+lex or yacc. We suggest you try regenerating the parser with a
+current version of flex or bison, respectively. In your own code, the
+appropriate fix is to move the initialization to the beginning of
+main.</p>
+
+<p>There is a common misconception that the GCC developers are
+responsible for GNU libc. These are in fact two entirely separate
+projects. The appropriate place to ask questions relating to GNU libc
+is <a href="mailto:libc-alpha@sources.redhat.com";>
+libc-alpha@sources.redhat.com</a>.
+</p></dd>
+
+<dt><em>Cannot use preprocessor directive in macro arguments.</em></dt>
+<dd><p>Let me guess... you wrote code that looks something like this:
+<blockquote><code>
+ memcpy(dest, src,
+#ifdef PLATFORM1
+ 12
+#else
+ 24
+#endif
+ );
+</code></blockquote>
+and you got a whole pile of error messages:
+<blockquote><code>
+
+test.c:11: warning: preprocessing directive not recognized within
+macro arg<br>
+test.c:11: warning: preprocessing directive not recognized within
+macro arg<br>
+test.c:11: warning: preprocessing directive not recognized within
+macro arg<br>
+test.c: In function `foo':<br>
+test.c:6: undefined or invalid # directive<br>
+test.c:8: undefined or invalid # directive<br>
+test.c:9: parse error before `24'<br>
+test.c:10: undefined or invalid # directive<br>
+test.c:11: parse error before `#'<br>
+</code></blockquote>
+
+The problem, simply put, is that GCC's preprocessor does not allow you
+to put <code>#ifdef</code> (or any other directive) inside the arguments of
+a macro. Your C library's <code><string.h></code> happens to
+define <code>memcpy</code> as a macro - this is perfectly legitimate.
+The code therefore will not compile.</p>
+
+<p>We have two good reasons for not allowing directives inside
+macro arguments. First, it is not portable. It is "undefined
+behavior" according to the C standard; that means different
+compilers will do different things with it. Some will give you
+errors. Some will dump core. Some will silently mangle your code -
+you could get the equivalent of</p>
+<pre>
+ memcpy(dest, src, 1224);
+</pre>
+<p>from the above example. A very few might do what you expected it
+to. We therefore feel it is most useful for GCC to reject this
+construct immediately so that it is found and fixed.</p>
+
+<p>Second, it is extraordinarily difficult to implement the
+preprocessor such that it does what you would expect for every
+possible directive found inside a macro argument. The best example is
+perhaps
+<blockquote><code>
+#define foo(arg) ... arg ...<br>
+foo(blah<br>
+#undef foo<br>
+blah)<br>
+</code></blockquote>
+which is <em>impossible</em> to implement in portable C without
+leaking memory. Allowing only a subset of directives would be
+confusing.</p>
+
+<p>It is always possible to rewrite code which uses conditionals
+inside macros so that it doesn't. You could write the above
+example
+<blockquote><code>
+#ifdef PLATFORM1<br>
+ memcpy(dest, src, 12);<br>
+#else<br>
+ memcpy(dest, src, 24);<br>
+#endif<br>
+</code></blockquote>
+This is a bit more typing, but I personally think it's better style
+in addition to being more portable.</p>
-<h2>Fortran</h2>
-<p> Fortran bugs are documented in the G77 manual rather than explicitly
-listed here. Please see <a href="onlinedocs/g77_bugs.html">"Known
-Causes of Trouble with GNU Fortran"</a> in the
-<a href="onlinedocs/g77_toc.html">G77 manual.</a>
+<p>In recent versions of glibc, <code>printf</code> is among the
+functions which are implemented as macros.</p></dd>
+</dl>
+<hr>
-<h2>C++</h2>
+<h2><a name="cplusplus">C++</a></h2>
<p>This is the list of bugs (and non-bugs) in g++ (aka GNU C++) that
are reported very often, but not yet fixed. While it is certainly
@@ -244,17 +395,22 @@ C++. This means that code which might ha
version, is now rejected. You should update your code to be C++.
<p>You should try to use the latest stable release of the GNU C++
-compiler. This is currently 3.0. Many commonly reported bugs in earlier
-releases are fixed in that version.
+compiler. This is currently 3.0. Many commonly reported bugs in
+earlier releases are fixed in that version.</p>
+
+<h3><a name="updating">Common problems updating from G++ 2.95 to G++
+3.0</a></h3>
-<h3>Common problems updating from g++ 2.95 to g++ 3.0</h3>
+<p>G++ 3.0 conforms much closer to the ISO C++ standard (available at
+<a href="http://www.ncits.org/cplusplus.htm";>http://www.ncits.org/cplusplus.htm</a>).</p>
-<p>g++ 3.0 conforms much closer to the ISO C++ standard (available at
-<a href="http://www.ncits.org/cplusplus.htm";>http://www.ncits.org/cplusplus.htm</a>).
-We have also implemented some of the core and library defect reports (available at
+<p>We have also implemented some of the core and library defect reports
+(available at
<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html";>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html</a>
&
-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html";>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html</a> respectively).
+<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html";>
+http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html</a>
+respectively).</p>
<ul>
@@ -311,65 +467,110 @@ header file, as you will be forcing user
same.
</ul>
+
+<h3><a name="nonbugs">Non-bugs</a></h3>
-<h3>Non-bugs</h3>
-Here are some features that have been reported as bugs, but are not.
+<p>Here are some features that have been reported as bugs, but are
+not.</p>
<dl>
-<dt>Nested classes can access private types of the containing class.
-<dd>G++ now implements type access control on member types. Defect
+<dt><em>Nested classes can access private types of the containing
+class.</em></dt>
+<dd><p>G++ now implements type access control on member types. Defect
report 45 clarifies that nested classes are members of the class they
-are nested in, and so are granted access to private members of that class.
+are nested in, and so are granted access to private members of that
+class.</p></dd>
-<dt>Classes in exception specifiers must be complete types.
-<dd>[15.4]/1 tells you that you cannot have an incomplete type, or
-pointer to incomplete (other than <code><it>cv</it> void *</code>) in an
-exception specification.
+<dt><em>Classes in exception specifiers must be complete
+types.</em></dt>
+<dd><p>[15.4]/1 tells you that you cannot have an incomplete type, or
+pointer to incomplete (other than <code><i>cv</i> void *</code>) in
+an exception specification.</p></dd>
-<dt>G++ emits two copies of constructors and destructors.
-<dd>In general there are <em>three</em> types of constructor (and destructor).
+<dt><em>G++ emits two copies of constructors and destructors.</em></dt>
+
+<dd><p>In general there are <em>three</em> types of constructors (and
+destructors).
<ol>
<li>The complete object constructor/destructor.
<li>The base object constructor/destructor.
<li>The allocating destructor/deallocating destructor.
</ol>
The first two are different, when virtual base classes are involved.
-In some cases we can do better, and this is logged in GNATS.
+In some cases we can do better, and this is logged in GNATS.</p>
+
+<dt><em>Exceptions don't work in multithreaded applications.</em></dt>
-<dt>Exceptions don't work in multithreaded applications
-<dd>You need to rebuild g++ and libstdc++ with --enable-threads.
-Remember, c++ exceptions are not like hardware interrupts. You cannot
-throw an exception in one thread and catch it in another. You cannot
-throw an exception from a signal handler, and catch it in the main
-thread.
-
-<dt>Global destructors are not run in the correct order
-<dd>Global destructors should be run in the reverse order of their
-constructors <em>completing</em>. In most cases this is the same as the
-reverse order of constructors <em>starting</em>, but sometimes it is
-different, and that is important. You need to compile and link your
+<dd><p>You need to rebuild g++ and libstdc++ with
+<code>--enable-threads</code>. Remember, c++ exceptions are not like
+hardware interrupts. You cannot throw an exception in one thread and
+catch it in another. You cannot throw an exception from a signal
+handler, and catch it in the main thread.</p></dd>
+
+<dt><em>Global destructors are not run in the correct order.</em></dt>
+<dd><p>Global destructors should be run in the reverse order of their
+constructors <em>completing</em>. In most cases this is the same as
+the reverse order of constructors <em>starting</em>, but sometimes it
+is different, and that is important. You need to compile and link your
programs with <code>--use-cxa-atexit</code>. We have not turned this
switch on by default, as it requires a <code>cxa</code> aware runtime
-library (<code>libc</code>, <code>glibc</code>, or equivalent).
+library (<code>libc</code>, <code>glibc</code>, or
+equivalent).</p></dd>
+
+<dt><em>Problems with floating point computations.</em></dt>
+<dd><p>In a number of cases, GCC appears to perform floating point
+computations incorrectly. For example, the program
+<blockquote><code>
+#include <iostream><br>
+<br>
+int main() {<br>
+<br>
+ double min = 0.0;<br>
+ double max = 0.5;<br>
+ double width = 0.01;<br>
+ std::cout << (int)(((max - min) / width) - 1) <<
+ std::endl;<br>
+<br>
+}<br>
+</code></blockquote>
+might print 50 on some systems and optimization levels, and 51 on
+others.</p>
+
+<p>The is the result of <em>rounding</em>: The computer cannot
+represent all real numbers exactly, so it has to use
+approximations. When computing with approximation, the computer needs
+to round to the nearest representable number.</p>
+
+<p>This is not a bug in the compiler, but an inherent limitation of
+the float and double types. Please study
+<a href="http://www.validgh.com/goldberg/paper.ps";>this paper</a>
+for more information.</p></dd>
</dl>
-<h3>Missing features</h3>
-We know some things are missing from g++.
+<h3><a name="missing">Missing features</a></h3>
+<p>We know some things are missing from G++.</p>
<dl>
-<dt><code>export</code> is not implemented.
-<dd>The keyword will be parsed correctly, but has no effect.
+<dt><em>The <code>export</code> keyword is not implemented.</em></dt>
+<dd><p>Most C++ compilers (G++ included) do not yet implement
+<code>export</code>, which is necessary for separate compilation of
+template declarations and definitions. Without <code>export</code>, a
+template definition must be in scope to be used. The obvious
+workaround is simply to place all definitions in the header
+itself. Alternatively, the compilation unit containing template
+definitions may be included from the header.</p></dd>
+
+<dt><em>Two stage lookup in templates is not implemented.</em></dt>
+<dd><p>[14.6] specifies how names are looked up inside a template. G++
+does not do this correctly, but for most templates this will not be
+noticeable.</p></dd>
-<dt>Two stage lookup in templates is not implemented.
-<dd>[14.6] specifies how names are looked up inside a template. G++ does
-not do this correctly, but for most templates this will not be noticeable.
-
-<dt>
+</dl>
-<h3><a name="parsing"></a>Parse errors for "simple" code</h3>
+<h3><a name="parsing">Parse errors for "simple" code</a></h3>
Up to and including GCC 3.0, the compiler will give "parse error" for
seemingly simple code, such as
@@ -439,10 +640,12 @@ exact error also somewhat varies with th
work-arounds proposed do not change the semantics of the program at
all; they make them perhaps less readable.
-<h3>Optimization at <code>-O3</code> takes a very long time</h3>
+<h3><a name="-O3">Optimization at <code>-O3</code> takes a
+very long time</a></h3>
<p>At <code>-O3</code>, all functions are candidates for inlining. The
heuristic used has some deficiencies which show up when allowed such
-freedom. This is g++ specific, as it has an earlier inliner than gcc.
+freedom. This is g++ specific, as it has an earlier inliner than
+gcc.</p>
</body>
</html>
Index: faq.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v
retrieving revision 1.165
diff -u -3 -p -r1.165 faq.html
--- faq.html 2001/07/04 12:51:47 1.165
+++ faq.html 2001/07/08 12:55:54
@@ -58,13 +58,6 @@ page</a>.</p>
<li><a href="#multipletests">How can I run the test suite with multiple options?</a></li>
</ol></li>
- <li><a href="#bugs">Bugs and Non-Bugs</a>
- <ol>
- <li><a href="#stdin">Why can't I initialize a static variable with <tt>stdin</tt>?</a></li>
- <li><a href="#macarg">Why can't I use #if here?</a></li>
- <li><a href="#rounding">Problems with floating point computations</a></li>
- </ol></li>
-
<li><a href="#old">Older versions of GCC or EGCS</a></li>
<ol>
<li><a href="#2.95suite">Why is there no testsuite in GCC 2.95?</a></li>
@@ -460,157 +453,6 @@ with <code>-fPIC</code>, once with <code
no additional flags.</p>
<p>This technique is particularly useful on multilibbed targets.</p>
-
-<hr>
-<a name="bugs"></a>
-<h1>Bugs and Non-Bugs</h1>
-
-<p>Unfortunately, improvements in tools that are widely used are
-sooner or later bound to break <em>something</em>. Sometimes, the
-code that breaks was wrong, and then that code should be fixed, even
-if it works for earlier versions of GCC or other compilers. The
-following problems with some releases of widely used packages have
-been identified:</p>
-
-<p>There is a separate <a href="bugs.html#known">list of well-known bugs</a>
-describing known deficiencies. Naturally we'd like that list to be of
-zero length.</p>
-
-<p>To report a bug, see <a href="bugs.html">How to report bugs</a>.</p>
-
-<hr>
-<h2><a name="stdin">Why can't I initialize a static variable with <tt>stdin</tt>?</a></h2>
-
-<p>This has nothing to do with GCC, but people ask us about it a
-lot. Code like this:</p>
-
-<pre>
- #include <stdio.h>
-
- FILE *yyin = stdin;
-</pre>
-
-<p>will not compile with GNU libc (Linux libc6), because
-<tt>stdin</tt> is not a constant. This was done deliberately, in
-order for there to be no limit on the number of open FILE objects. It
-is surprising for people used to traditional Unix C libraries, but it
-is permitted by the C standard.</p>
-
-<p>This construct commonly occurs in code generated by old versions of
-lex or yacc. We suggest you try regenerating the parser with a
-current version of flex or bison, respectively. In your own code, the
-appropriate fix is to move the initialization to the beginning of
-main.</p>
-
-<p>There is a common misconception that the GCC developers are
-responsible for GNU libc. These are in fact two entirely separate
-projects. The appropriate place to ask questions relating to GNU libc
-is <a href="mailto:libc-alpha@sources.redhat.com";>libc-alpha@sources.redhat.com</a>.
-</p>
-
-<hr>
-<h2><a name="macarg">Why can't I use #if here?</a></h2>
-
-<p>Let me guess... you wrote code that looks something like this:</p>
-<pre>
- memcpy(dest, src,
-#ifdef PLATFORM1
- 12
-#else
- 24
-#endif
- );
-</pre>
-<p>and you got a whole pile of error messages:</p>
-<pre>
-test.c:11: warning: preprocessing directive not recognized within macro arg
-test.c:11: warning: preprocessing directive not recognized within macro arg
-test.c:11: warning: preprocessing directive not recognized within macro arg
-test.c: In function `foo':
-test.c:6: undefined or invalid # directive
-test.c:8: undefined or invalid # directive
-test.c:9: parse error before `24'
-test.c:10: undefined or invalid # directive
-test.c:11: parse error before `#'
-</pre>
-
-<p>The problem, simply put, is that GCC's preprocessor does not allow
-you to put #ifdef (or any other directive) inside the arguments of a
-macro. Your C library's <tt>string.h</tt> happens to define
-<tt>memcpy</tt> as a macro - this is perfectly legitimate. The code
-therefore will not compile.</p>
-
-<p>We have two good reasons for not allowing directives inside
-macro arguments. First, it is not portable. It is "undefined
-behavior" according to the C standard; that means different
-compilers will do different things with it. Some will give you
-errors. Some will dump core. Some will silently mangle your code -
-you could get the equivalent of</p>
-<pre>
- memcpy(dest, src, 1224);
-</pre>
-<p>from the above example. A very few might do what you expected it
-to. We therefore feel it is most useful for GCC to reject this
-construct immediately so that it is found and fixed.</p>
-
-<p>Second, it is extraordinarily difficult to implement the
-preprocessor such that it does what you would expect for every
-possible directive found inside a macro argument. The best example is
-perhaps</p>
-<pre>
-#define foo(arg) ... arg ...
-foo(blah
-#undef foo
-blah)
-</pre>
-<p>which is <emph>impossible</emph> to implement in portable C without
-leaking memory. Allowing only a subset of directives would be
-confusing.</p>
-
-<p>It is always possible to rewrite code which uses conditionals
-inside macros so that it doesn't. You could write the above
-example</p>
-<pre>
-#ifdef PLATFORM1
- memcpy(dest, src, 12);
-#else
- memcpy(dest, src, 24);
-#endif
-</pre>
-<p>This is a bit more typing, but I personally think it's better style
-in addition to being more portable.
-
-<p>In recent versions of glibc, <code>printf</code> is among the
-functions which are implemented as macros.
-
-<h2><a name="rounding">Problems with floating point computations</a></h2>
-
-<p>In a number of cases, GCC appears to perform floating point
-computations incorrectly. For example, the program</p>
-<pre>
-#include <iostream>
-
-int main() {
-
- double min = 0.0;
- double max = 0.5;
- double width = 0.01;
- std::cout << (int)(((max - min) / width) - 1) << std::endl;
-
-}
-</pre>
-<p>might print 50 on some systems and optimization levels, and 51 on
-others.</p>
-
-<p>The is the result of <em>rounding</em>: The computer cannot
-represent all real numbers exactly, so it has to use
-approximations. When computing with approximation, the computer needs
-to round to the nearest representable number.</p>
-
-<p>This is not a bug in the compiler, but an inherent limitation of
-the float and double types. Please study
-<a href="http://www.validgh.com/goldberg/paper.ps";>this paper</a>
-for more information.</p>
<hr>
<a name="old"></a>