bug#36370: 27.0.50; XFIXNAT called on negative numbers

[Paul Eggert <eggert@cs.ucla.edu>]

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.