Open p5pRT opened 8 years ago
The documentation for & in perlfunc states that
Binary "&" returns its operands ANDed together bit by bit.
Implicit in this is that both operands are always evaluated\, even if the LHS has a bit pattern of all zeroes. The operator does not short cut like &&. I think the documentation should state this explicitly.
Further\, can perl guarantee that on all platforms
0 & 0 == 0 0 & 1 == 0 1 & 0 == 0 1 & 1 == 1
0 | 0 == 0 0 | 1 == 1 1 | 0 == 1 1 | 1 == 1
0 ^ 0 == 0 0 ^ 1 == 1 1 ^ 0 == 1 1 ^ 1 == 0
You can imagine some funky processor where the integer 0 has a bit pattern which isn't all zeroes\, for example\, so the above equations wouldn't hold. But I don't think Perl runs on any such architecture in practice. If minimally it could be guaranteed that the bitwise ops behave as expected with the integer values 0 and 1\, they would be more useful in programming.
Ed Avis wrote:
The operator does not short
cut like &&. I think the documentation should state this explicitly.
Should the documentation for infix * also clarify that 0*$a doesn't short-circuit? I'm not really opposed to that kind of clarification\, but we should be consistent about it.
Further\, can perl guarantee that on all platforms
Yes\, that is guaranteed.
You can imagine some funky processor where the integer 0 has a bit pattern which isn't all zeroes\,
The C language standard requires that the representations of unsigned and non-negative signed integers be pure binary place value. Thus the representation of zero is always all bits zero. The bitwise operators are defined to operate on the binary place value representations. Perl depends on this aspect of C all over the place\, and effectively passes that guarantee on to Perl programs using Perl's bitwise operators. Perl further requires that the negative signed representation be twos-complement\, and so guarantees that too to Perl programs.
It is conceivable for a platform to use a different numeric representation at a very low level\, but its C implementation must then include enough translation to successfully pretend that it's pure binary. Such translation is outside our area of concern.
-zefram
The RT System itself - Status changed from 'new' to 'open'
Migrated from rt.perl.org#129371 (status was 'open')
Searchable as RT129371$