Pip Cet wrote:
This is not a valid use of 'assume'. It's documented that assume's argument
should be free of side effects.
But the compiler makes no such assumption
Sure, but if the caller uses 'assume' contrary to its documentation, that's a
problem with the caller's code, not with 'assume'. It's merely an implementation
detail as to which pothole the problematic code runs into.
if GCC decided to add a
__builtin_assume() builtin, we could give it slightly different
semantics: that the expression passed to it evaluates to true, but
doesn't evaluate to false or fail to evaluate. Something like
__attribute__((does_return)) might do on a function.
Yes, the expression should return true without side effects or looping. I don't
see this as an significant difference in semantics. One should also not call
Gnulib assume (R) with an expression that loops forever, as this defeats the
intent of 'assume' which is to make code more efficient. If there's any real
confusion about this issue, we can add it to the 'assume' documentation as well.
Also, "should" doesn't mean "must", does it?
It's not the "should" of an Internet RFC. It's more the "should" of "you should
do this, and if you don't you're on your own".
I'd prefer rewording that
sentence as "R may or may not be evaluated: it should not normally
have side-effects".
Better to say that it should not have side effects at all. There's no "normally"
about that. Side effects are trouble.
wouldn't it be even
nicer to give up (most of) the distinction between assert and assume
and just tell people to use assume?
No, because 'assert (false)' has well-defined behavior, whereas behavior is
undefined for programs that do 'assume (false)' . This is a fundamental
difference between the two.
