From: Jeff King <peff@peff.net>
To: David Kastrup <dak@gnu.org>
Cc: John Keeping <john@keeping.me.uk>, git@vger.kernel.org
Subject: Re: [PATCH 1/5] notes-utils: handle boolean notes.rewritemode correctly
Date: Tue, 18 Feb 2014 02:46:32 -0500 [thread overview]
Message-ID: <20140218074632.GA29804@sigill.intra.peff.net> (raw)
In-Reply-To: <87txbzvxgq.fsf@fencepost.gnu.org>
On Sun, Feb 16, 2014 at 05:22:45PM +0100, David Kastrup wrote:
> Not really relevant to this patch, but looking at the output of
>
> git grep config_error_nonbool
>
> seems like a serious amount of ridiculousness going on. The header
> shows
>
> cache.h:extern int config_error_nonbool(const char *);
> cache.h:#define config_error_nonbool(s) (config_error_nonbool(s), -1)
>
> and the implementation
>
> config.c:#undef config_error_nonbool
> config.c:int config_error_nonbool(const char *var)
You could always look in the commit history:
$ git log -S'#define config_error_nonbool' cache.h
or search the mailing list:
http://thread.gmane.org/gmane.comp.version-control.git/211505
> Presumably this was done so that the uses of config_error_nonbool can be
> recognized as returning -1 unconditionally.
Yes, it helps prevent false positives in gcc's flow analysis
(specifically, -Wuninitialized warnings).
> But is that worth the obfuscation?
Yes?
> Why not let config_error_nonbool return -1 in the first place?
It originally did, but callers do not get to see the static return, so
they miss some analysis opportunities.
> It does not appear like any caller would call the function rather than
> the macro, so why declare the function as returning an int at all?
Because we don't use these macros on non-gnu compilers; they actually
see the real function return.
> And why give it the same name as the macro (risking human/computer
> confusion and requiring an explicit #undef for the definition or was
> that declaration?) instead of config_error_nonbool_internal or
> whatever else?
This particular case is simple, but see error() for another use of the
same technique which requires variadic macros, which are not available
everywhere. Callers want to say just "error(...)", so we have to name
the macro that. If we call the matching function "error_internal", then
non-gnu compilers would need a macro to convert "error(...)" to
"error_internal(...)". But they can't do so, because it would be a
variadic macro.
So you could adjust config_error_nonbool(), but not error(). But that
introduces its own confusion, because the technique is not applied
consistently.
I agree the #define is ugly. But it's confined to a small area, and it
does solve an actual problem.
-Peff
next prev parent reply other threads:[~2014-02-18 7:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-16 16:06 [PATCH 0/5] Miscellaneous fixes from static analysis John Keeping
2014-02-16 16:06 ` [PATCH 1/5] notes-utils: handle boolean notes.rewritemode correctly John Keeping
2014-02-16 16:22 ` David Kastrup
2014-02-18 7:46 ` Jeff King [this message]
2014-02-18 8:41 ` David Kastrup
2014-02-18 9:01 ` Jeff King
2014-02-18 9:36 ` David Kastrup
2014-02-16 16:06 ` [PATCH 2/5] utf8: fix iconv error detection John Keeping
2014-02-16 16:06 ` [PATCH 3/5] utf8: use correct type for values in interval table John Keeping
2014-02-16 16:06 ` [PATCH 4/5] builtin/mv: don't use memory after free John Keeping
2014-02-16 16:06 ` [PATCH 5/5] streaming: simplify attaching a filter John Keeping
2014-02-18 23:56 ` Junio C Hamano
2014-02-19 0:02 ` Junio C Hamano
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=20140218074632.GA29804@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=john@keeping.me.uk \
/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).