On 3/7/21 8:09 PM, Lénárd Szolnoki via Std-Discussion wrote:
> On Sun, 07 Mar 2021 18:52:26 +0300
> Andrey Semashev via Std-Discussion <std-discussion_at_[hidden]>
> wrote:
>
>> On March 7, 2021 6:26:41 PM Jason McKesson via Std-Discussion
>> <std-discussion_at_[hidden]> wrote:
>>
>>> On Sun, Mar 7, 2021 at 4:14 AM Andrey Semashev via Std-Discussion
>>> <std-discussion_at_[hidden]> wrote:
>>>>
>>>> On 3/6/21 10:34 PM, Jason McKesson via Std-Discussion wrote:
>>>>> On Sat, Mar 6, 2021 at 12:55 PM Vishal Oza via Std-Discussion
>>>>> <std-discussion_at_[hidden]> wrote:
>>>>>>
>>>>>> I was thinking of making the bit and bitset libraries as well
>>>>>> bit manipulation operators with the exception of endian and
>>>>>> possibly left and right bitshift to undefined behavior if the
>>>>>> base is not 2 in hardware.
>>>>>
>>>>> Um, what exactly does that mean?
>>>>>
>>>>> Here's what I mean. If you have the number 15, and you do a
>>>>> binary-left-shift it by 2, the number you get is 30. It *does not
>>>>> matter* how the hardware implements this. So long as `30 == 15 <<
>>>>> 2` is true, the implementation is doing its job.
>>>>>
>>>>> Similarly, if you have the number 15, and you do a bitwise-and
>>>>> with 2, you get the number 13. Again, how the hardware does this
>>>>> is irrelevant; the implementation's job is to make the math work
>>>>> out.
>>>>
>>>> Bit manipulation operators affect bit representation of a number,
>>>> the resulting value is a consequence of that. In that sense,
>>>> before we mandated two's complement representation, applying bit
>>>> operators to signed integers would yield implementation-dependent
>>>> numbers, although the effect on bit representation (with some
>>>> restrictions) was well defined.
>>>
>>> Bitwise operations on signed integers, pre-twos complement, were
>>> defined so long as the source integers were positive and the
>>> resulting value could be stored in a signed integer of that type.
>>>
>>> Also, don't forget that a specification describes behavior, not
>>> implementation.
>>
>> Sure, my point is that the specification describes behavior in terms
>> of bit representation. The effect on the value is the consequence.
>>
>> You could rewrite the spec to define behavior in terms of integer
>> values, but that would be useless for the binary world, and it's not
>> clear how useful that would be for platforms of different bases.
>>
>
> The standard already describes behavior in terms of values, not bit
> representation. Value representation of integers are not even specified
> outside of intN_t/uintN_t, so it can't be specified based on that.
>
> http://eel.is/c++draft/expr.shift#2
>
> http://eel.is/c++draft/expr.shift#3

The notes in both these sections speak in terms of bit representation.
Granted, notes are not normative.

For bitwise operators the standard speaks in terms of bits:

http://eel.is/c++draft/expr.bit.and
http://eel.is/c++draft/expr.xor
http://eel.is/c++draft/expr.or