On Fri, Dec 9, 2011 at 12:48 PM, Marc Lehmann <schm...@schmorp.de> wrote: > none of which seem to influence correctness in a bad way, unlike your > proposed changes. > > you see, we have basically these choices: > > a) possibly break code in unexpected ways on some far away box, but have > fewer warnings on an obsoleted proprietary platform that is known to be > buggy beyond repair. > b) possibly have a few warnings by an overzealous compiler (or compiler user > specifying extra warnings) but correct code and execution maybe a bit > slower on some obsolete proprietary box. > > without your patch, b) is implemented, with your patch we move to a). > > I don't think a few warnings are reason enough to risk it. Especially as > the root cause is the dubious decision of (some) llvm (-based compilers) > to implement subsets of gcc extensions but announcing full support for gcc > extensions. > > I am just surprised they didn't do that with c99. Or maybe they didn't, > but we don't know yet. > > Now, if you want to track which version of llvm-gcc announces which > version of gcc and actually implements ALL the extensions by that version > of gcc that is fine, and might lead to ecb changing. > > However, llvm-gcc is long obsolete - clang would be more relevant, and > much more relevant would be dragonegg, which will without doubt eventually > replace it even on outdated os x boxes, so supporting it for fewer > warnings and slightly faster code in some corner cases is just not worth > your time, imho.
What do you think of my latest patch which only whitelists Apple's llvm-gcc specifically, and only if the advertised version is large enough? -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands) _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
