 |
lua-l archive |
|
|
||
|
William Ahern wrote:
On Tue, Mar 25, 2014 at 01:31:06PM -0400, Ralph Hempel wrote:Dirk Laurie wrote:2014-03-25 18:20 GMT+02:00 Paul Baker<paulbaker8@gmail.com>:Regarding the new bitwise operators, the Reference Manual states "Both right and left shifts fill with zeros the vacant bits". Given that "Lua 5.3 has integers but not unsigned integers" [1], it seems strange that the>> operator is unsigned rather than signed. Is there a reason for this? Personally, I think it would be useful for Lua to support both types of right shift - perhaps using the same syntax as JavaScript:>> and>>> ?Don't agree. I can see the point of arithmetic shift in C, where it could be useful when programming multiprecision arithmetic ??? but C does not have it. Its inclusion in the bit32 library always felt to me like a loving preservation of a quirk of some early computer (IBM 360 springs to mind).I believe that the result of a shift in C must preserve the implied "signedness" of the value being shifted. For the case of signed values, a right shift will fill high order bits with the value of the MSB.Right shifting a signed type with a negative value has implementation-defined behavior. Left shifting a signed type with a negative value has undefined-behavior. See N1570 (C11) 6.5.7 p4 and p5.
William, thanks for the correction on my overly eager use of the word "must"What I should have said (and what has been echoed in this thread) is that most of the production C compilers I have used implement arithmetic shift right for signed integers.
And left shifting a signed value will be undefined, yes.Maybe if we get burned by assuming how things work, we can refer to them as singed integers :-)
Ralph Ralph