Re: ~0 undefined?
On Oct 20, 10:19 pm, blargg....@gishpuppy.com (blargg) wrote:
In article
<cdcc86af-9c2f-4fe7-9b77-dc7c45315...@w24g2000prd.googlegroups.com>, Jame=
s
Kanze <james.ka...@gmail.com> wrote:
blargg wrote:
Does ~0 yield undefined behavior? C++03 section 5 paragraph 5 seems to
suggest so:
If during the evaluation of an expression, the result is
not mathematically defined or not in the range of
representable values for its type, the behavior is
undefined [...]
The description of unary ~ (C++03 section 5.3.1 paragraph
8):
The operand of ~ shall have integral or enumeration type;
the result is the one's complement of its operand.
Integral promotions are performed. The type of the result
is the type of the promoted operand. [...]
But perhaps "one's complement" means the value that type
would have with all bits inverted, rather than the
mathematical result of inverting all bits in the binary
representation. For example, on a machine with 32-bit int,
does one's complement of 0 (attempt to) have the value
2^31-1, which can't be represented in a signed int and is
thus undefined,
[...]
The problem here is that the "one's complement" operation
doesn't really define a numeric result, but rather a
manipulation on the underlying representation. So I don't
think that this statement [C++03 section 5 paragraph 5] can
be applied: the ~ operator changes the bits in the
representation, and the "result" is whatever value the
changed bits happen to represent. Except that it's not
really too clear what that means, either; what happens if
the changed bits would be a trapping representation? (E.g.
a 1's complement machine that traps on negative 0's.)
So you're saying that n = ~n, where n is an int, could be
implemented as
for ( size_t i = 0; i < sizeof n; ++i )
reinterpret_cast<unsigned char*> (&n) [i] ^= (unsigned char) -1=
;
where it's up to the implementation as to the new value n
takes on.
Pretty much. After having posted this, I checked in the C99
standard (where the wording concerning the representation of
integral types has been completely redone, since it was felt
that the original wording wasn't entirely clear). There, it's
much clearer: the operator is described as doing a "bitwise
complement" (and not a one's complement), and in the text
describing representation of integers, it explicitly says that
this operator can result in a negative zero (supposing such
exists in the representation), and if the implementation doesn't
support negative zeros, the behavior is undefined.
(As I interpret it, there are three possibilities: negative zero
can't exist---that's the case for 2's complement---, or if they
exist, the implementation can support them or not, where
"support them" means more or less that you can use them, and
they will work as expected. The C99 does explicitly say that a
negative zero can be a trapping value.)
This would imply that the following are guaranteed
to hold true, regardless of n's signedess or sign:
~~n == n
(n & ~n) == 0
(n ^ ~n) == ~0
(n & ~0) == n
(n & ~1) == n - (n & 1)
With the proviso that it's implementation defined whether ~n can
result in a negative 0 or not, and if it does, it's
implementation defined how this value behaves, and it may result
in undefined behavior. I'm not sure about the last, I haven't
had time to analyse it, but they others certainly hold *IF*
there is no undefined behavior.
As a general rule, however, I would look askance at any code
which used bitwise operators on signed values, with a few
exceptions (mainly, masking just the low order bits, i.e. x &
0x0F or x & 0xFF).
This is the interpretation I really hope is the case.
Because of such issues, I tend to avoid using ~, | or & on
signed integral types.
That would require ensuring all bitwise constants are
unsigned,
Not necessarily. You rarely operate on two constants, and if
the other, non-constant operator is unsigned, the operation will
be unsigned. The unary operator ~ is a special case, but you
generally need to specify the exact type when using it anyway,
in order to ensure the proper length.
by suffixing with a U, casting, or storing in an unsigned type
before use, which seems somewhat tedious. As in my example,
even code for simply testing the low bit would require a nasty
U: n&1U.
Do you think so? The results of masking all but the lower bits
will always be non-negative, and the problems only occur with
negative results. It's the one exception I would allow.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34