<div>On Wed Jan 15 2014 at 11:51:24 AM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>On Wed, Jan 15, 2014 at 3:41 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 15/01/2014 06:04, Nico Weber wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does gcc allow this for C? Is C planning on standardizing this?<br>
</blockquote>
<br></div>
The impression I get is that everybody's doing it but nobody's talking about it. Yet.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div><div><div>Clarified on irc. gcc doesn't implement this, Alp meant that some people carry local patches to add this support.</div>
<div><br></div><div>I'm skeptical of adding this if there's no standardization movement for this and no other compilers support this yet :-/</div></div></div></div></blockquote><div><br></div><div>I agree. As far as I'm aware, we would be the *only* production C compiler to support C++ attribute syntax. The good news is that we already have a policy on allowing such extension: <a href="http://clang.llvm.org/get_involved.html">http://clang.llvm.org/get_involved.html</a></div>
<div><br></div><div>The only point where this extension falls down is point 4. Here's what the C committee said about N1403 (see minutes in N1475):</div><div><br></div><div><div>Do you support double square brackets? [[ ]]</div>
<div> Yes – 4</div><div> No – 15</div><div> Abs – 3</div><div><br></div><div>Do we want a syntax for non-Standard extensions?</div><div> Yes – 4</div><div> No – 12</div><div> Abs – 6</div></div><div> <br></div><div>I think it's fair to say we would *not* have the support of the C committee here.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ISO C is reactionary so if we set a sensible standard there's a reasonable shot at getting it adopted. Likewise OpenMP and other dialects -- they'll go with the mainstream.<br>
<br>
This is also why we should use a name that's already recognised like "generalized attributes." Language bodies simply won't accept a foreign name like "C++ attributes" -- it has never happened before, given how fiercely independent these committees are -- so they'll end up each going their own route, choosing their own names. It's a better plan to consolidate proactively here.<br>
<br>
My view is that it matters because we're working with the people designing these standards and they respect our decisions when we put time into getting them right.<br>
<br>
Of there'll always be those with Richard Smith's point of view that "we really don't need to worry about theoretical future C17 or OpenMP constructs now" -- but assuming we do care (and I do), these are issues that matter.<br>
<br>
Alp.<br>
<br>
<br>
<br>
<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<br>
On Tue, Jan 14, 2014 at 5:50 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a> <mailto:<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><u></u>> wrote:<br>
<br>
On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith<br></div><div>
<<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a> <mailto:<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><u></u>> wrote:<br>
<br>
On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a><br></div><div><div>
<mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
This patch generalizes C++11 attributes for use in C and<br>
C-like dialects, and additionally enables the new syntax<br>
as an extension to C11.<br>
<br>
<br>
Why do you allow this by default in C11? And conversely, why<br>
not in C90 / C99?<br>
<br>
<br>
I think maybe this was unclear. I'd prefer one of these two options:<br>
<br>
1) A -fcxx-attributes argument (or similar) to enable C++<br>
attribute syntax outside C++ (and either do or don't allow them by<br>
default in C++98), or<br>
2) C++ attributes available by default in all language modes.<br>
<br>
I'd prefer the first option (defaulting to following the language<br>
standard more strictly) -- I think this would be the first time we<br>
enabled a C++ language feature in C modes, if we went with the<br>
second option.<br>
<br>
If we're going to allow these anywhere by default, C++98 would<br>
seem like a good place to start. I don't believe they<br>
introduce any ambiguities outside of Objective-C(++), and we<br>
already disambiguate those cases. (There's an ambiguity with<br>
lambdas, but we don't need to address that until/unless we<br>
allow lambdas in C++98.)<br>
<br>
All features are carried forward from C++11, including<br>
usage on declarations, attributed statements, scoped<br>
attribute names, GNU attribute aliases and the<br>
clang-specific attribute namespace.<br>
<br>
A new feature detection macro is provided, breaking from<br>
the usual c/cxx prefix convention in order to facilitate<br>
portable detection in C++ and C modes:<br>
<br>
__has_feature(attributes) - 1 in C++11, otherwise 0.<br>
__has_extension(attributes) - 1 in C++11 and C11, otherwise 0.<br>
<br>
<br>
This is already available as __has_feature(cxx_attributes);<br>
using __has_extension(cxx_<u></u>attributes) in C would seem to be<br>
the right approach here (we're allowing C++ attributes as an<br>
extension in C). This is what we already do for C99 and C11<br>
features which we accept in C++.<br>
<br>
The new warning flag -W(no-)generalized-attributes<br>
suppresses the new extension warning in C. The same flag<br>
can also be used to selectively disable attribute<br>
compatibility warnings produced by the pre-existing<br>
-Wc++98-compat option.<br>
<br>
<br>
OK, so this is why you wanted us to pick a name for this<br>
feature; you're going to use it as a diagnostic name. I think<br>
this should be called -Wc++-attributes, to match our existing<br>
compatible-for-all-time feature name cxx_attributes. We can<br>
add an alias to a better name if we ever need one, but for<br>
now, we're pretty clearly allowing a C++ feature in C, so<br>
calling it "c++-something" makes sense to me.<br>
<br>
Newly added tests have been shared with C++11 where<br>
possible to ensure consistency between language modes.<br>
<br>
<br>
Does this do the right thing for (for instance)<br>
<br>
struct S {<br>
[[ gnu::aligned(8) ]] int n;<br>
};<br>
<br>
? (Structs use different parsing code in C and C++. )<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-commits mailing list<br></div></div>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.<u></u>edu</a>><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a><br>
<br>
<br>
</blockquote><div><div>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div></div></div></blockquote>