Does gcc allow this for C? Is C planning on standardizing this?
On Tue, Jan 14, 2014 at 5:50 PM, Richard Smith <[email protected]>wrote: > On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith <[email protected]>wrote: > >> On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker <[email protected]> wrote: >> >>> This patch generalizes C++11 attributes for use in C and C-like >>> dialects, and additionally enables the new syntax as an extension to C11. >>> >> >> Why do you allow this by default in C11? And conversely, why not in C90 / >> C99? >> > > I think maybe this was unclear. I'd prefer one of these two options: > > 1) A -fcxx-attributes argument (or similar) to enable C++ attribute syntax > outside C++ (and either do or don't allow them by default in C++98), or > 2) C++ attributes available by default in all language modes. > > I'd prefer the first option (defaulting to following the language standard > more strictly) -- I think this would be the first time we enabled a C++ > language feature in C modes, if we went with the second option. > > >> If we're going to allow these anywhere by default, C++98 would seem like >> a good place to start. I don't believe they introduce any ambiguities >> outside of Objective-C(++), and we already disambiguate those cases. >> (There's an ambiguity with lambdas, but we don't need to address that >> until/unless we allow lambdas in C++98.) >> >> >>> All features are carried forward from C++11, including usage on >>> declarations, attributed statements, scoped attribute names, GNU attribute >>> aliases and the clang-specific attribute namespace. >>> >>> A new feature detection macro is provided, breaking from the usual c/cxx >>> prefix convention in order to facilitate portable detection in C++ and C >>> modes: >>> >>> __has_feature(attributes) - 1 in C++11, otherwise 0. >>> __has_extension(attributes) - 1 in C++11 and C11, otherwise 0. >>> >> >> This is already available as __has_feature(cxx_attributes); using >> __has_extension(cxx_attributes) in C would seem to be the right approach >> here (we're allowing C++ attributes as an extension in C). This is what we >> already do for C99 and C11 features which we accept in C++. >> >> The new warning flag -W(no-)generalized-attributes suppresses the new >>> extension warning in C. The same flag can also be used to selectively >>> disable attribute compatibility warnings produced by the pre-existing >>> -Wc++98-compat option. >>> >> >> OK, so this is why you wanted us to pick a name for this feature; you're >> going to use it as a diagnostic name. I think this should be called >> -Wc++-attributes, to match our existing compatible-for-all-time feature >> name cxx_attributes. We can add an alias to a better name if we ever need >> one, but for now, we're pretty clearly allowing a C++ feature in C, so >> calling it "c++-something" makes sense to me. >> >> Newly added tests have been shared with C++11 where possible to ensure >>> consistency between language modes. >> >> >> Does this do the right thing for (for instance) >> >> struct S { >> [[ gnu::aligned(8) ]] int n; >> }; >> >> ? (Structs use different parsing code in C and C++. ) >> > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
