Author: Omid David Tabibi
Date: 13:49:24 02/08/04
Go up one level in this thread
On February 08, 2004 at 13:22:38, Dieter Buerssner wrote: >On February 08, 2004 at 12:55:54, Sune Fischer wrote: > >>On February 08, 2004 at 12:05:12, Dieter Buerssner wrote: >> >>>6.5.7 Bitwise shift operators >>> >>>[...] If the value of the right operand is negative or is >>>greater than or equal to the width of the promoted left operand, the behavior is >>>undefined. >> >>I knew about the negative shift but not the latter. >>I wonder why that is the case, I see no reason why it should be undefined. > >It is not supported by common hardware. For example x86 will shift by >shift-count mod 32 for 32 bit registers. Other hardware may produce a zero. >Demanding one definition would make code run very slow on the other hardware. > >>>A warning would be useful anyway for a constant expression. Gcc: left shift >>>count >= width of type. >> >>It's just a way of writing a constant, ie. would you also want a warning on 1<<2 >>saying that constant 1 being altered to 4? > >Of course not. That has not much to do with the original example. Anyway - no >constant is altered anyway - a constant expression is evaluated. > >>The compilers intent would be to tell you that if you want 4 and not 1, why not >>just write 4 instead of 1? > >This is typical usage. A shift count > the width of the type is probably almost >always an error (in Standard C always). > >>A 64 bit compiler might treat "1" as a __int64 by default, not sure what the >>"ANSI" should be on that if it ever gets formally extended to include 64 bit >>variables. > >It got already formally extended (MSVC does not support it). If you want a >constant to mean an unsigned long long, you have to write 1ULL (unsigned long >long contains at least 64 bits). MSVC uses a similar convention for __int64. >It is very similar to what we already have. Assume int is 16 bit (which is >allowed in Standard C). > >long x = 1 << 23; > >will not do what might be intended. > >long x = 1L << 23; > >will do it. The later will work on any Standard C compiler, the former not. If >you don't care about compilers with 16 bit int, it might still be useful. There >are compilers where sizeof(long) > sizeof(int), and there will probably be more >in the future. > That's why I *never* use the long variable :) Everywhere I just use int or unsigned int, and where the variable must be 32 bit (like some attack tables), I use a typedefed UINT32. The problem with that unsigned __int64 a = 1 << 50 is that it is the last thing you suspect when something goes wrong. For several hours I was helplessly tracing an obscure bug. After failing to find the bug, I just did a printf(%I64u\n", a) out of desperation. And to my surprise, 0 was the result printed out to screen. If the compiler wants to regard that (1 << 50) as 32 bit, it must at least display a warning. But anyway, this was not the first time that I have seen MSVC not displaying any warning where it definitely should. >It is also similar with long doubles. > >Regards, >Dieter
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.