This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C,C++] integer constants in attribute arguments
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>
- Date: Sun, 2 Feb 2014 19:12:23 +0000
- Subject: Re: [C,C++] integer constants in attribute arguments
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1311301103070 dot 10346 at stedding dot saclay dot inria dot fr> <52C5DD73 dot 2070305 at redhat dot com> <alpine dot DEB dot 2 dot 02 dot 1401182314190 dot 23143 at stedding dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 10 dot 1402012058150 dot 3649 at laptop-mg dot saclay dot inria dot fr> <Pine dot LNX dot 4 dot 64 dot 1402021840450 dot 17960 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 10 dot 1402021943450 dot 3633 at laptop-mg dot saclay dot inria dot fr>
On Sun, 2 Feb 2014, Marc Glisse wrote:
> An alternative could be to have a helper function that does nothing in C and
> calls default_conversion in C++. Or make the C version of default_conversion
> return its argument unchanged instead of asserting when it sees an unexpected
> tree.
Well, in principle I'm dubious about the cases where different
implementations of functions with the same name are used in c-family code;
I'd prefer an actual C/C++ set of langhooks, with clearly defined
semantics based on what the c-family users need, where the hook used
(c_family_lang_hooks.convert_attribute_argument or whatever) would indeed
do nothing for C. But more than just default_conversion is involved
there, and default_conversion is already used from c-family code, so this
isn't an objection to this patch.
--
Joseph S. Myers
joseph@codesourcery.com