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

[Hongli Lai]

On Fri, Dec 9, 2011 at 12:48 PM, Marc Lehmann <schmorp at 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: info at phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)