Sending upstream [was: Patches for compilig with clang accepted?]

12 views
Skip to first unread message

Thomas Braun

unread,
May 2, 2013, 3:35:11 PM5/2/13
to msy...@googlegroups.com
> On Thu, May 2, 2013 at 4:52 PM, Thomas Braun
> <thomas...@virtuell-zuhause.de> wrote:
>> Hi,
>>
>> I managed to create a llvm+clang mingw package [1]. With that I compiled
>> msysgit/git using
>>
>> make CFLAGS="-g -O2 -Wall -Werror -Wno-format-invalid-specifier" CC=clang
>>
>> and some errors popped up which I fixed and would deem upstream-pushable.
>> See the attachement or https://github.com/t-b/git/commits/clang-fixes.
>> Maybe it makes also sense to send 9d07211 and e81eb32 to upstream git?
>>
>
> These patches doesn't touch Windows-only code, so this is probably not
> the right list for them; clang is interesting for non-Windows users
> also. But nice work!
>
> As for the actualy patches, the third one looks bogus to me; "array +
> index" is a common way of getting the address of an element in an
> array; if claing complains about this, it going to complain about a
> *lot* of perfectly reasonable code. I seem to remember that very
> change being discussed upstream, though.

You are right, I should have checked at upstream first.
The change in
0001-Don-t-check-if-an-unsigned-value-is-negative.patch
was accepted in upstream git in 3ce3ffb.
And 0003-Use-the-correct-syntax-for-pointer-arithmetic.patch was heavily
laughed about so far... So I guess I just ignore that for now.
Anyway one can always use

make CFLAGS="-g -O2 -Wall -Werror -Wno-format-invalid-specifier
-Wno-string-plus-int -Wno-tautological-compare" CC=clang

I'll try to get
0002-Add-pragma-to-ignore-the-warning-for-clang-also.patch upstream at
gnulib as that is the real source for poll.c.

Thomas

Erik Faye-Lund

unread,
May 2, 2013, 3:52:45 PM5/2/13
to Thomas Braun, msy...@googlegroups.com
Please use "reply all" when replying in the future ;)

On Thu, May 2, 2013 at 9:35 PM, Thomas Braun
Yeah, it can be worked around. It makes me a little bit annoyed that
one would have to do so, but IMO it's better than modifying the code.

However, it seems this is a special case for string-literals...
perhaps making COLONS a global variable instead would make it go away
without having to explicitly silence the warning?

> I'll try to get 0002-Add-pragma-to-ignore-the-warning-for-clang-also.patch
> upstream at gnulib as that is the real source for poll.c.

That makes a lot of sense :)

Again, thanks for the work! I've been wanting to play around with
clang on Windows for a while, I guess I'll have a closer look at your
work soon!
Reply all
Reply to author
Forward
0 new messages