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
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
