Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 11 Oct 2013 02:55:44 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> >> While the programmer may have written her C code under the assumption
> >> that an asserted condition holds, the compiler can't know that the
> >> asserted condition holds when generating its machine code. The point of
> >> the assume mechanism is to provide this information to the compiler.
> >
> > The compiler will be unable to take advantage of that information,
> > because there's no source code to apply that information to.
> 
> I don't understand this argument. In my example, the assume would inform 
> the compiler that it didn't have to emit code to handle division in the 
> case that *b is zero.

I think Stephen explained this already.

> >>> In most cases, you won't see any code that can be optimized
> >>> out using this assumption, as the programmer already did that --
> >>> that's why she added the assertion in the first place.
> >>
> >> At the C level, not the code generation level.
> >
> > Code is generated from the C code, not out of thin air.
> 
> And we're talking about giving the compiler more information about the C 
> code.

Information about C code that just isn't there will not help the
compiler.

> If the programmer really expects an assertion not to hold, he can
> use a variant that doesn't assume the condition holds. But these
> cases should be rare.

You are wrong: in Emacs, these cases are the vast majority.  Just take
a look at the code which uses assertions.

> >>> For now, yes.  I'm afraid that's just the tip of the iceberg, though.
> >>
> >> What other problems can you imagine?
> >
> > How should I know?  Does anyone know under which conditions, exactly,
> > a badly engineered bridge will collapse?
> 
> So this point boils down to "I have a bad feeling about this"?

No, it boils down to "this is bad engineering".

> >>> The problem is to make sure an assertion obviously _is_ free of side
> >>> effects.  With Emacs's massive use of macros, which call other macros,
> >>> which call other macros, which... -- that is extremely hard.  And why
> >>> should a programmer who just wants to assert something go to such
> >>> great lengths?  That is just a maintenance burden for which I find no
> >>> good justification.
> >>
> >> What great lengths? Most common macros --- things like EQ --- are
> >> clearly free of side effects.
> >
> > There are a lot of macros much more complex than EQ.
> 
> So don't use the assume-and-assert macros for questionable cases.

People tend to forget subtle and obscure factoids.  The risk of any
one of us to forget and just treat this macro as a function call is
real.  See bug #15565 as a clear example.

> >> The more exotic assertions probably aren't worth assuming anyway.
> >
> > Not sure I understand what you are saying here.
> 
> I'm speculating that the optimization value to be gained from assuming 
> very complex conditions is smaller than the value gained for assuming 
> relatively simple conditions.

But if assume-and-assert macro exists, this abuse is exactly what is
going to happen.

> AFAICT, your opposition here boils down to the idea that there's some 
> fundamental difference between, on one hand, statements we make about 
> program behavior when we're debugging, and on the other hand, statements 
> we make about program behavior when we're optimizing.

Yes.

> Except for some cases involving deficiencies in the language-level
> mechanisms with which we make these statements, I don't see why we
> should regard these statements as different at all.

Again, explained by Stephen.  You will find in Emacs sources gobs of
examples of what Stephen shows.

> You could argue that having two macros instead of one imposes a 
> maintenance burden and that there isn't a payoff sufficient to justify 
> this burden, but I don't think the maintenance cost of having another 
> macro is very large, especially if we leave existing assertions as they 
> are and use the assume-and-assert macro only for cases that are clearly 
> free of side effects.

I submit that in most cases determining whether an expression is free
of side effects is prohibitively time consuming.  As result, people
will simply not do that analysis, and we will have more bugs like
15565.