From: John Keeping <john@keeping.me.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Antoine Pelisse <apelisse@gmail.com>
Subject: Re: [PATCH 2/3] combine-diff: suppress a clang warning
Date: Sun, 3 Feb 2013 20:31:50 +0000 [thread overview]
Message-ID: <20130203203150.GU1342@serenity.lan> (raw)
In-Reply-To: <7vwqup890o.fsf@alter.siamese.dyndns.org>
On Sun, Feb 03, 2013 at 11:58:15AM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > When compiling combine-diff.c, clang 3.2 says:
> >
> > combine-diff.c:1006:19: warning: adding 'int' to a string does not
> > append to the string [-Wstring-plus-int]
> > prefix = COLONS + offset;
> > ~~~~~~~^~~~~~~~
> > combine-diff.c:1006:19: note: use array indexing to silence this warning
> > prefix = COLONS + offset;
> > ^
> > & [ ]
> >
> > Suppress this by making the suggested change.
> >
> > Signed-off-by: John Keeping <john@keeping.me.uk>
> > ---
>
> This was not lost in the noise.
>
> I thought that this wasn't a serious patch, but your attempt to
> demonstrate to others why patches trying to squelch clang warnings
> are not necessarily a good thing to do.
>
> Who is that compiler trying to help with such a warning message?
> After all, we are writing in C, and clang is supposed to be a C
> compiler. And adding integer to a pointer to (const) char is a
> straight-forward way to look at the trailing part of a given string.
A quick search turned up the original thread where this feature was
added to Clang [1]. It seems that it does find genuine bugs where
people try to log values by doing:
log("failed to handle error: " + errno);
[1] http://thread.gmane.org/gmane.comp.compilers.clang.scm/47203
> > - prefix = COLONS + offset;
> > + prefix = &COLONS[offset];
>
> In other words, both are perfectly valid C. Why should we make it
> less readable to avoid a stupid compiler warning?
Are you happy to change COLONS to a const char[] instead of a #define?
That also suppresses the warning.
Since Git is warning-free on GCC and so close to being warning-free on
recent Clang I think it is worthwhile to fix the remaining two issues
which do seem to be intentional diagnostics rather than Clang bugs.
John
next prev parent reply other threads:[~2013-02-03 20:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-03 14:37 [PATCH 0/3] Make Git compile warning-free with Clang John Keeping
2013-02-03 14:37 ` [PATCH 1/3] fix clang -Wtautological-compare with unsigned enum John Keeping
2013-02-03 19:38 ` Jonathan Nieder
2013-02-03 14:37 ` [PATCH 2/3] combine-diff: suppress a clang warning John Keeping
2013-02-03 18:20 ` Tay Ray Chuan
2013-02-03 19:06 ` John Keeping
2013-02-03 19:58 ` Junio C Hamano
2013-02-03 20:31 ` John Keeping [this message]
2013-02-03 21:07 ` Junio C Hamano
2013-02-03 23:15 ` John Keeping
2013-02-04 0:24 ` Junio C Hamano
2013-02-05 20:25 ` [PATCH] t4038: add tests for "diff --cc --raw <trees>" John Keeping
2013-02-05 20:48 ` Junio C Hamano
2013-02-05 21:39 ` [PATCH v2] " John Keeping
2013-02-05 22:27 ` Junio C Hamano
2013-02-07 4:12 ` [PATCH 2/3] combine-diff: suppress a clang warning Miles Bader
2013-02-07 8:41 ` John Keeping
2013-02-03 14:37 ` [PATCH 3/3] builtin/apply: tighten (dis)similarity index parsing John Keeping
2013-02-03 20:50 ` Junio C Hamano
2013-02-03 17:13 ` [PATCH 0/3] Make Git compile warning-free with Clang Antoine Pelisse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130203203150.GU1342@serenity.lan \
--to=john@keeping.me.uk \
--cc=apelisse@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).