Am 27.07.2013 um 03:18 schrieb Arthur O'Dwyer: > Jonathan, I don't think that's a good argument. You've already pointed > out that the test for "does Clang support this feature" is as simple > as "#if defined(__clang__) && (__clang_major__ > 3 || (__clang_major__ > == 3 && __clang_minor__ >= 4))". You object that such a test would > leave out bleeding-edge versions of Clang between now and the 3.4 > release; but that's a very short-term problem that will go away in a > few months, whereas __has_feature() introduces a problem that will by > definition be around for the rest of everyone's life.
I'm ok with not having a __has_feature(), but some ABI version define instead. Having a check like the above is hacky at least. Is there any valid reason against having an __OBJFW_RUNTIME_ABI_VERSION__ define when -fobjc-runtime=objfw is used that I can increase from time to time when necessary? > (Besides, this is Objective-C. The Objective-C compiler is a > fast-moving target, and generates silly and/or crashy code on a > regular basis for sufficiently obscure constructs. Forwarding a method > that returns a struct by value, using a particular non-Apple non-GNU > runtime and a particular compiler built from source within a small > time window, seems like the very definition of "sufficiently > obscure".) I have to say that at least on x86_64 and x86, I never had Clang trunk emit crashing code in the past year. Other platforms is a different story though, and there the problems were even with pure C. However, I think having an attitude that is "It's fine if it crashes for some old Clang snapshot" or "It's ok to use an evil hack to check for it instead of doing it right" is wrong, no matter how obscure something is. If you can do it right, do it right. If a __has_feature is not the right way, then there is some other, like the define I proposed. John, would you be ok with me going ahead and adding a define __OBJFW_RUNTIME_ABI_VERSION__ when -fobjc-runtime=objfw is used? That would be sufficient for me. I would just increase that number in case a similar situation arises in the future. -- Jonathan _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
