Re: Logical shift

[Sean Conner <sean@...>]

It was thus said that the Great D Burgess once stated:
> Forgive me if this has been previously noted:
> The 5.3 manual says
> >  All bitwise operations convert its operands to integers (see §3.4.3), operate on all bits of those integers, and result in an integer.
> > Both right and left shifts fill the vacant bits with zeros.
> 
> In other words an "unsigned" shift or logical shift. No sign extension.
> 
> Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> > string.format("0x%016x",(1<<63)>>8)
> 0x0080000000000000
> 
> Bash
> # printf '0x%016x\n' $(( (1<<63)>>8 ))
> 0xff80000000000000
> 
> PHP
> printf '0x%016x\n' $(( (1<<63)>>8 ))
> 0xff80000000000000
> 
> Perl
> # perl -e 'printf "0x%016x\n",(1<<63)>>8'
> 0x0080000000000000
> 
> SQLite 3.29.0
> sqlite> select printf('0x%016x',(1<<63)>>8);
> 0xff80000000000000
> 
> *I wish this was highlighted in the manual.*
> 
> What was the reasoning in choosing logical shift for >> rather than arithmetic?

  From the C89 standard (ISO/IEC 9899:1990), section 6.3.7 (emphasis added):

	The result of El >> E2 is El right-shifted E2 bit positions. If El
	has an unsigned type or if El has a signed type and a nonnegative
	value, the value of the result is the integral part of the quotient
	of El divided by the quantity, 2 raised to the power E2. If El has a
	signed type and a negative value, the resulting value is
	implementation-defined.
	^^^^^^^^^^^^^^^^^^^^^^

  From that, I would assume that the only way to ensure consistent values
across all C compilers is to only do unsigned shifts.

  -spc