From: Jeff King <peff@peff.net>
To: Brandon Richardson <brandon1024.br@gmail.com>
Cc: Duy Nguyen <pclouds@gmail.com>, Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] commit-tree: utilize parse-options api
Date: Thu, 28 Feb 2019 15:56:33 -0500 [thread overview]
Message-ID: <20190228205633.GA12199@sigill.intra.peff.net> (raw)
In-Reply-To: <CAETBDP42djjmSXeLig6mcRJVR0YMPnDUfCJT4z8SU==Ei62N4w@mail.gmail.com>
On Wed, Feb 27, 2019 at 10:46:49PM -0400, Brandon Richardson wrote:
> > If we are going to go this route, I think you might actually want macros
> > that take both "unset" and "args" and make sure that we're not in a
> > situation the callback doesn't expect (e.g., "!unset && !arg"). That
> > lets us continue to declare those at the top of the callback.
>
> In doing a quick search, I found a fair number instances of this:
> ...
> BUG_ON_OPT_NEG(unset);
>
> if (!arg)
> return -1;
> ...
Those are probably my fault. The originals guarded against an unexpected
"unset" by checking "!arg" and returning an error. But it made the
compiler's -Wunused-parameter complain, so I added the BUG_ON_OPT_NEG()
calls as an assertion. At that point the "if (!arg)" could never
trigger, and could have been removed.
> So a macro like this could be useful. I've also found a few instances of this:
>
> BUG_ON_OPT_NEG(unset);
> BUG_ON_OPT_ARG(arg);
These ones are different. The second one is checking that "arg" _is_
NULL (i.e., we expect that the options struct provided the right flag to
disallow an argument). And that's orthogonal to the unset flag, so it
would not be right to conflate the two in a single macro.
-Peff
prev parent reply other threads:[~2019-02-28 20:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-26 20:09 [PATCH] commit-tree: utilize parse-options api Brandon
2019-02-26 22:38 ` Andrei Rybak
2019-02-26 23:42 ` Brandon Richardson
2019-02-27 11:13 ` Duy Nguyen
2019-02-27 11:07 ` Duy Nguyen
2019-02-27 11:37 ` SZEDER Gábor
2019-02-27 11:49 ` Duy Nguyen
2019-02-27 12:36 ` SZEDER Gábor
2019-02-28 7:21 ` Duy Nguyen
2019-02-27 15:24 ` Brandon Richardson
2019-02-28 7:26 ` Duy Nguyen
2019-02-27 16:35 ` Jeff King
2019-02-28 2:46 ` Brandon Richardson
2019-02-28 20:56 ` Jeff King [this message]
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=20190228205633.GA12199@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=brandon1024.br@gmail.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.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).