libecb patch: fix compile warnings on gcc-llvm 4.2.1 (OS X 10.6 with Xcode 4)

Hongli Lai hongli at
Fri Dec 9 12:59:39 CET 2011

On Fri, Dec 9, 2011 at 12:48 PM, Marc Lehmann <schmorp at> 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

Phusion | Ruby & Rails deployment, scaling and tuning solutions

E-mail: info at
Chamber of commerce no: 08173483 (The Netherlands)

More information about the libev mailing list