From: Jeff King <peff@peff.net>
To: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: Junio C Hamano <gitster@pobox.com>,
GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH] usage: fix a sparse 'redeclared with different type' error
Date: Mon, 15 May 2017 23:02:00 -0400 [thread overview]
Message-ID: <20170516030200.fivl7p5iukfxk2jb@sigill.intra.peff.net> (raw)
In-Reply-To: <52ef158a-0719-c71a-b72b-4961cf8f96d5@ramsayjones.plus.com>
On Tue, May 16, 2017 at 02:11:40AM +0100, Ramsay Jones wrote:
>
> If you need to re-roll your 'jk/bug-to-abort' branch, could you please
> squash this into the relevant patch (commit d8193743e0 "usage.c: add
> BUG() function", 12-05-2017).
>
> [Just FYI, sparse complains thus:
> usage.c:212:6: error: symbol 'BUG_fl' redeclared with different type
> (originally declared at git-compat-util.h:1076) - different modifiers
> ]
Hmm. Our model here is the die() function, which gets noreturn and
format attributes in the declaration, but only noreturn at the
definition.
Your patch here adds both attributes to the definition:
> +__attribute__((format (printf, 3, 4))) NORETURN
> void BUG_fl(const char *file, int line, const char *fmt, ...)
Another possible model is trace_printf_key_fl(), which just has a format
attribute at the declaration, and nothing at all in the definition.
So it seems like this doesn't matter for the format attribute, but does
for NORETURN. Weird. I wonder if it's specific to the attribute, or
something about the way we hide it behind a macro.
There probably isn't a downside to repeating the format attribute, I
guess. Except that I'm not sure what happens if the two ever got out of
sync (gcc doesn't seem to complain, though in practice you'd probably
change the order or number of arguments at the same time, which is
likely to cause a mismatch).
-Peff
next prev parent reply other threads:[~2017-05-16 3:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-16 1:11 [PATCH] usage: fix a sparse 'redeclared with different type' error Ramsay Jones
2017-05-16 3:02 ` Jeff King [this message]
2017-05-16 12:27 ` Ramsay Jones
2017-05-23 1:02 ` Luc Van Oostenryck
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=20170516030200.fivl7p5iukfxk2jb@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ramsay@ramsayjones.plus.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.