Hello, >> following the discussion in cfe-dev[*], I decided to put my money where my >> mouth is and have attached a patch >> that makes it possible to use __has_feature(__feature__) in place of >> __has_feature(feature) to protect the >> feature name in case the user defines a macro with the same name. >> >> I modeled the patch after the similar handling of __attribute__ names. > > This patch looks great to me, please commit!
As I have not commit access, I would kindly ask someone who has to do it for me. I updated the patch to include Jean-Daniel's suggestion to handle __has_extension the same way. I also modified the code slightly to make the normalization of the name work without invoking undefined behaviour in case the string is shorter than 4 characters: Before, it depended on the assumption that an unsigned integer underflow would result in a very large integer, which was then ignored as it was larger than the string size. As this also was the case when normalizing the attribute name, I modified that code as well. I don't think that a feature "has_feature_supports_double_underscore" or similar is necessary. Simply choose an arbitrary extension that is always supported in clang and check for the feature with and without underscores: #if __has_extension(c_alignas) && !__has_extension(__c_alignas__) # message Double underscores in extension names are not supported #else # message Double underscores in extension names are supported #endif If you disagree, just tell me and I'll add it. I have attached the new patch. Jonathan
underscore_features.diff
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
