This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Projects for beginners
- To: zackw at Stanford dot EDU
- Subject: Re: Projects for beginners
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sat, 10 Mar 2001 21:05:15 -0500 (EST)
- Cc: gcc at gcc dot gnu dot org, jsm28 at cam dot ac dot uk, neil at daikokuya dot demon dot co dot uk
> From: "Zack Weinberg" <zackw@Stanford.EDU>
> >
> > Fair enough.
> >
> > But in the mean time, as I toyed with implementing it myself, I
> > realized that the current "poison" behaves exactly as I wanted for the
> > new feature. Apparently Zack's description about it triggering on
> > macros was wrong.
>
> I was just about to suggest that we change it so it works this way. I
> think it'll be a lot more useful.
>
> Wanna fix the documentation to match?
> zw
How's this? It probably needs to be applied to both the head and the
branch.
--Kaveh
2001-03-10 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* cpp.texi (poison): Explain macro expansion exception.
--- cpp.texi~ Sat Mar 3 06:32:32 2001
+++ cpp.texi Sat Mar 10 20:47:30 2001
@@ -1601,6 +1601,23 @@ sprintf(some_string, "hello");
@noindent
will produce an error.
+Note, if the poisoned identifier appears through the result of macro
+expansion it won't cause an error.
+
+For example,
+
+@example
+#define strrchr rindex
+#pragma GCC poison rindex
+strrchr(some_string, 'h');
+@end example
+
+@noindent
+will not produce an error. This is useful because you may wish to
+enforce using the ISO C functions in your source code but the platform's
+system headers define them in terms of the BSD variants. The above
+exception allows these factors to coexist.
+
@node Macro Pitfalls,, Poisoning, Macros
@subsection Pitfalls and Subtleties of Macros
@cindex problems with macros