This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[www-patch] bugs.html rewrite, part 3: C part of non-bugs section
- From: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- To: gcc-patches at gcc dot gnu dot org
- Date: Thu, 04 Sep 2003 20:48:35 +0200 (CEST)
- Subject: [www-patch] bugs.html rewrite, part 3: C part of non-bugs section
- Reply-to: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
Here's the third part of the bugs.html rewrite.
It changes the introduction and the C part of the non-bugs section
It actually touches only the first example in the C part, since
the second looks OK to me.
Remarks:
* I got rid of line 11 in the error message, since that's what I get
with GCC 2.95.3.
* The change in behaviour of the preprocessor really came with
the 3.3 release.
Verified as XHTML 1.0.
Ok to commit?
Regards,
Volker
Index: bugs.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs.html,v
retrieving revision 1.75
diff -u -p -r1.75 bugs.html
--- bugs.html 20 Aug 2003 15:33:56 -0000 1.75
+++ bugs.html 3 Sep 2003 00:50:51 -0000
@@ -435,11 +435,13 @@ Trouble with GNU Fortran</a> in the G77
<p>The following are not actually bugs, but are reported often
enough to warrant a mention here.</p>
-<p>Programming languages themselves change. Earlier versions of GCC
-might have accepted source code that is <em>no longer</em> valid.
-This means that code which might have "worked" in a previous version,
-is now rejected. You should update your code to match recent language
-standards (this holds especially for C++).</p>
+<p>It is not always a bug in the compiler, if code which "worked" in a
+previous version, is now rejected. Earlier versions of GCC sometimes were
+less picky about standard conformance and accepted invalid source code.
+In addition, programming languages themselves change, rendering code
+invalid that used to be conforming (this holds especially for C++).
+In either case, you should update your code to match recent language
+standards.</p>
<hr />
@@ -481,7 +483,8 @@ for more information.</p></dd>
<dl>
<dt>Cannot use preprocessor directive in macro arguments.</dt>
-<dd><p>Let me guess... you wrote code that looks something like this:</p>
+<dd><p>Let me guess... you used an older version of GCC to compile code
+that looks something like this:</p>
<blockquote><pre>
memcpy(dest, src,
#ifdef PLATFORM1
@@ -501,20 +504,22 @@ test.c:6: undefined or invalid # directi
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></blockquote>
-<p><strong>Update:</strong> As of GCC 3.2 this kind of construct is
-always accepted and CPP will probably do what you expect, but see the
-manual for detailed semantics.</p>
-
-<p>However, versions of GCC prior to 3.2 did 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 would not compile.</p>
+<p>This is because your C library's <code><string.h></code> happens
+to define <code>memcpy</code> as a macro - which is perfectly legitimate.
+In recent versions of glibc for example, <code>printf</code> is among the
+functions which are implemented as macros.</p>
+
+<p>Versions of GCC prior to 3.3 did not allow you to put <code>#ifdef</code>
+(or any other directive) inside the arguments of a macro. The code therefore
+would not compile.</p>
+
+<p>As of GCC 3.3 this kind of construct is always accepted and the
+preprocessor will probably do what you expect, but see the manual for
+detailed semantics.</p>
-<p>This kind of code is not portable. It is "undefined behavior"
+<p>However, this kind of code is not portable. It is "undefined behavior"
according to the C standard; that means different compilers will do
different things with it. It is always possible to rewrite code which
uses conditionals inside macros so that it doesn't. You could write
@@ -527,10 +532,8 @@ the above example</p>
#endif
</pre></blockquote>
<p>This is a bit more typing, but I personally think it's better style
-in addition to being more portable.</p>
+in addition to being more portable.</p></dd>
-<p>In recent versions of glibc, <code>printf</code> is among the
-functions which are implemented as macros.</p></dd>
<dt>Cannot initialize a static variable with <code>stdin</code>.</dt>
<dd><p>This has nothing to do with GCC, but people ask us about it a
===================================================================