On Mon, Nov 27, 2017 at 02:39:43PM -0500, Jeff Hostetler wrote:
> On 11/22/2017 5:56 PM, Stefan Beller wrote:
> > On Tue, Nov 21, 2017 at 12:58 PM, Jeff Hostetler <[email protected]>
> > wrote:
> > > + assert(arg);
> > > + assert(!unset);
> >
> > I count 16 asserts in this patch. Is that really needed?
> > Either omit them or use BUG if we want to rely on user
> > bug reports when these conditions trigger, as assert is unreliable
> > due to its dependence on the NDEBUG flag.
>
> Yes, there are a few asserts in the code. Old habits....
>
> I could remove some/all of them, but personally I feel they
> have merit and hint to the mindset of the author for future
> readers of the code. Are there other opinions?
I think I'd prefer in general to see assertions remain in one form or
another, if only because of the documentation benefits you mention here.
I do think there's such a thing as too many asserts, but I don't think I
see that here. "Too many" would probably be something like asserting
things that are a normal part of the contract (so "assert(foo)" on
every pointer parameter coming in to make sure it's not NULL).
I thought at first that's what was happening with the ones quoted above,
but it's actually documenting that no, we do not support "--no-filter"
in opt_parse_list_objects_filter (which is really checking that we're in
sync with the PARSE_OPT_NONEG found elsewhere).
So arguably my confusion argues that this one ought to have a custom
message or a comment.
Of course, it also makes me wonder whether we ought to just support
--no-filter. Shouldn't it just set us back to FILTER_DISABLED?
> Personally, I think it might be awkward to keep repeating
> something like:
>
> if (!c)
> BUG(msg);
>
> Do we want to think about a macro that builds on BUG() and
> does the test?
>
> Something like:
> #define ASSERT_OR_BUG(c) do { if (!(c)) BUG("%s", #c); } while (0)
Yeah, I think that was where the other thread[1] led to. IMHO that's
probably what BUG_ON() ought to do (though personally I'm fine with just
continuing to use assert for simple cases).
I think we can sidestep the whole variadic-macros thing mentioned in
that thread since we don't take a custom message.
-Peff
[1] https://public-inbox.org/git/[email protected]/
