This is awkward, but the bitwise AND operator is defined in the C++ standard as follows (emphasis mine).
The usual arithmetic conversions are performed; the result is the bitwise AND function of its operands. The operator applies only to integral or unscoped enumeration operands.
This looks kind of meaningless to me. The "bitwise AND function" is not defined anywhere in the standard, as far as I can see.
I get that the AND function is well-understood and thus may not require explanation. The meaning of the word "bitwise" should also be rather clear: the function is applied to corresponding bits of its operands. However, what constitute the bits of the operands is not clear.
What gives?
This is underspecified. The issue of what the standard means when it refers to bit-wise operations is the subject of a few defect reports.
For example defect report 1857: Additional questions about bits:
The specification of the bitwise operations in 5.11 [expr.bit.and], 5.12 [expr.xor], and 5.13 [expr.or] uses the undefined term “bitwise” in describing the operations, without specifying whether it is the value or object representation that is in view.
Part of the resolution of this might be to define “bit” (which is otherwise currently undefined in C++) as a value of a given power of 2.
and the response was:
CWG decided to reformulate the description of the operations themselves to avoid references to bits, splitting off the larger questions of defining “bit” and the like to issue 1943 for further consideration.
and defect report 1943 says:
CWG decided at the 2014-06 (Rapperswil) meeting to address only a limited subset of the questions raised by issues 1857 and 1861. This issue is a placeholder for the remaining questions, such as defining a “bit” in terms of a value of 2n, specifying whether a bit-field has a sign bit, etc.
We can see from this defect report 1796: Is all-bits-zero for null characters a meaningful requirement?, that this issue of what the standard means when it refers to bits affected/affects other sections as well:
According to 2.3 [lex.charset] paragraph 3,
The basic execution character set and the basic execution wide-character set shall each contain all the members of the basic source character set, plus control characters representing alert, backspace, and carriage return, plus a null character (respectively, null wide character), whose representation has all zero bits.
It is not clear that a portable program can examine the bits of the representation; instead, it would appear to be limited to examining the bits of the numbers corresponding to the value representation (3.9.1 [basic.fundamental] paragraph 1). It might be more appropriate to require that the null character value compare equal to 0 or '\0' rather than specifying the bit pattern of the representation.
There is a similar issue for the definition of shift, bitwise and, and bitwise or operators: are those specifications constraints on the bit pattern of the representation or on the values resulting from the interpretation of those patterns as numbers?
In this case the resolution was to change:
representation has all zero bits
to:
value is 0.
Note that as mentioned in ecatmur's answer the draft C++ standard does defer to C standard section 5.2.4.2.1
in section 3.9.1
[basic.fundamental] in paragraph 3
it does not refer to section 6.5/4
from the C standard which would at least tell us that the results are implementation defined. I explain in my comment below that C++ standard can only incorporate text from normative references explicitly.