git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: Jeff King <peff@peff.net>
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 09:41:51 +0100	[thread overview]
Message-ID: <87vbwcstgw.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <20140218074632.GA29804@sigill.intra.peff.net> (Jeff King's message of "Tue, 18 Feb 2014 02:46:32 -0500")

Jeff King <peff@peff.net> writes:

> On Sun, Feb 16, 2014 at 05:22:45PM +0100, David Kastrup wrote:
>> 
>> 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?

gcc's flow analysis works with the same data as humans reading the
code.  If there is no information content in the function call, it makes
more sense to either making it void.

One can always explicitly write

  (config_error_nonbool("panic-when-assailed"), -1)

for shortcircuit use inside of an expression even when
config_error_nonbool is a function returning a void expression: comma
operators do not try type coercion on their first argument.

Shrug.  This one has likely been discussed to death already.  Sometimes
it's more convenient to avoid getting a question asked in the first
place rather than having a stock answer for it.

-- 
David Kastrup

  reply	other threads:[~2014-02-18  8:42 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
2014-02-18  8:41       ` David Kastrup [this message]
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=87vbwcstgw.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=john@keeping.me.uk \
    --cc=peff@peff.net \
    /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).