This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: __attribute__((deprecated)) (revision2)
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: Gabriel Dos Reis <gdr at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, Ira Ruben <ira at apple dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: 09 Jan 2002 04:05:11 +0100
- Subject: Re: [PATCH]: __attribute__((deprecated)) (revision2)
- Organization: CodeSourcery, LLC
- References: <Pine.LNX.4.33.0201081533220.15767-100000@kern.srcf.societies.cam.ac.uk>
"Joseph S. Myers" <jsm28@cam.ac.uk> writes:
| On 8 Jan 2002, Gabriel Dos Reis wrote:
|
| > Richard Henderson <rth@redhat.com> writes:
| >
| > | On Mon, Dec 17, 2001 at 05:29:10PM -0800, Ira Ruben wrote:
| > | > + { "deprecated", 0, 0, false, false, false,
| >
| > Well, I would like us not to step into user name-space with our own
| > extension. What about __deprecated__ (we already have __unused__).
|
| All attributes have __ and non-__ forms. (Before table-driven attributes
| some machine attributes were inconsistent in this regard, but now all
| attributes work like this and the compiler checks in init_attributes that
| the tables don't include anything beginning and ending with __, if
| ENABLE_CHECKING.)
That answer my question. Thanks!
| Of course we could (should?) make the manual use the __
| forms in examples, just noting that the non-__ forms are available if you
| don't care about possible macros.
That sounds very good to me.
-- Gaby
CodeSourcery, LLC http://www.codesourcery.com