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. How the implementation does it is irrelevant as long
as it comes up with the right answer. Even defining signed integers as
twos complement is all about behavior: what happens when you convert a
signed integer to unsigned and vice-versa. You can implement that
behavior without using twos complement in the actual hardware. It'd be
complicated, yes, but you can do it.