Am 27.07.2013 um 01:54 schrieb John McCall: > The feature enables users to rely on arbitrary message forwarding if they're > willing to live on certain minimum compiler and runtime versions. That’s a > pretty simple and comprehensible message for users. > > In fact, if I remember correctly, we didn’t actually support generating code > correctly for your runtime until fairly recently, so your users are all > perfectly aware of the concept of a minimum compiler version.
You are oversimplifying things here. There was no support for the ObjFW runtime before 3.2, but that didn't mean that Clang 3.1 could not work with it: It could, and it worked well, it was just that certain features were unavailable. This, however, is different. It will mean that using an old Clang version or GCC will generate *crashing code* instead of a feature being unavailable. That's a completely different thing! Crashing code is *totally* inacceptable! GNU used to be ok with crashing code (there was a lot in their runtime that just crashed one some CPU architectures), but that doesn't mean we need to be as bad as they were. IMHO, code should never crash, period. It should check for the define I provide and if it absolutely relies on the feature error out, or of it's optional disable it. > I really doubt that your users are going to write > preprocessor-conditionalized code so that they can figure out whether they’re > running on the one single compiler + runtime configuration that supports a > major restructuring of their code to rely on arbitrary message forwarding. I doubt even more they want code crashing if they don't even have a chance to check beforehand if it will crash. Heck, it's not even possible to write a reliable test for stret as it's HIGHLY architecture dependent. It really is the only way to check if Clang emits objc_msg_lookup_stret(). > The policy of clang is not to introduce __has_feature checks for bug fixes. Then we need to find something else. Maybe introduce some OBJFW_RUNTIME_ABI_VERSION define when the ObjFW runtime is used that gets increased on changes like this. But just crashing and not having any way to check beforehand if it will crash is just unacceptable. So there has to be some way to expose it to code. It's always better to error out at compile time then to crash at runtime. And sometimes it's even possible to disable an optional feature that requires stret forwarding, so that the difference is between crashing and just a feature missing. Sorry for my harsh words, but for me, there is just no excuse for code to crash. Erroring out is better then crashing, and disabling an optional feature is also ok if it prevents crashing. -- Jonathan _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
