On Thu, Dec 08, 2011 at 11:18:44PM +0100, Hongli Lai <hon...@phusion.nl> wrote: > > hmm, I am curious, what kind of warnings are these?
hmm, these are harmless and can be ignored, and possibly switched off if they are a nuisance. > I don't know whether it's fully implemented, but everything that ecb.h > uses *is* fully implemented in llvm-gcc 4.2.1. This is pretty huge > because Xcode 4 now uses llvm-gcc as the default gcc so all OS X users > will get these warnings. well, warnings do not influence correctness, so it's not really a big deal. > llvm-gcc 4.2.1 on OS X does support C99, but it doesn't advertise that > unless you specify -std=c99. In fact it doesn't set __STDC_VERSION__ > at all unless you pass that argument. then thats an easy workaround, just compile libecb in c99 mode, for improved performance even :) > I see that forcing ECB_C99 also gets rid of most of the compilation > warnings so the problem was with ecb_inline after all. However this > still leaves all the other problems as mentioned above. 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. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list firstname.lastname@example.org http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev