[systemd-devel] [PATCH 2/2] macro: allow assert_se() assertions to also be optimized out when NDEBUG is set

[Djalal Harouni]

On Fri, Mar 27, 2015 at 09:51:26AM -0700, Shawn Landden wrote:
> On Fri, Mar 27, 2015 at 8:16 AM, Tom Gundersen <teg at jklm.no> wrote:
[...]
> >> * Current expression may modify/interact with a global state which may
> >>   cause a fatal error, and if the caller wants to know if that failed,
> >>   then abort(), your patch just introduced a regression, without the
> >>   explicit abort(), all callers now have to call abort().
> >
> > Yeah, this is the point I think. I still think the patch makes sense
> > though, it really don't see why there should be a distinction between
> > assert_se() and assert() when it comes to logging and aborting.
> >
> > If assert_se() fails it indicates we may have messed up the global
> > state, and if assert() fails it indicates that the global state may be
> > messed up (by someone else). Either way the global state is
> > potentially messed up and not logging/aborting seems as (un)safe in
> > both situations.
> >
> > Another way of seeing it, intuitively I don't see why we should
> > distinguish between
> >
> > assert_se(foo() >= 0);
> >
> > and
> >
> > r = foo();
> > assert(r >= 0);
> Yes. The use case is that embedded people don't want all the strings
> that the logging adds to their binaries when these are ASSERTS, they
> are only expected to catch programming errors. It is not to make it
> faster, I think that is negligible.
Hmm embedded cases are real, I had to deal with some in the past. But
not sure here since I didn't see any numbers before/after stripping, but
perhaps you can start by updating the callers and their semantics if you
think that the code there is robust and it's worth it... ?

Thanks!

-- 
Djalal Harouni
http://opendz.org