Author: Robert Hyatt
Date: 11:02:52 06/07/04
Go up one level in this thread
On June 07, 2004 at 12:53:03, Eugene Nalimov wrote: >On June 07, 2004 at 12:06:48, Robert Hyatt wrote: > >>On June 07, 2004 at 10:46:28, Uri Blass wrote: >> >>>On June 07, 2004 at 10:40:09, Fabien Letouzey wrote: >>> >>>>On June 07, 2004 at 10:36:58, Vincent Diepeveen wrote: >>>> >>>>>On June 07, 2004 at 10:30:50, Fabien Letouzey wrote: >>>> >>>>>r = 1<<36; // works for good compilers not for the rest >>>> >>>>Hm, my understanding is that first "1<<36" should be calculated (so it's 0 if >>>>sizeof(int) <= 4) and *then* cast into r's type (oops, too late). >>>> >>>>Fabien. >>> >>>A smart compiler should understand that 1<<36 cannot mean 0 because in that case >>>the programmer has no reason to write it in that way. >>> >>>The only logical meaning of 1<<36 is that it is a 64 bit number(espacially when >>>r is defined as a 64 bit number). >>> >>>Uri >> >> >>That would violate every C standard on the planet. And break more programs than >>it would help. > >Technically speaking it will not violate the standard. For this particular case >standard says "result is undefined", so compiler is free to replace ((long long) >(1 << 36)) by (((long long) 1) << 36). Of course it will create lot of other >problems, because you don't want such transformation for non-constant shift >amount. I was thinking of the inverse. The standard says "undefined". But the compiler now handles it in a specific way and advertises it as such in the docs. And now you end up with a compiler saying "it works this way" when the standard doesn't agree... > >Visual C 2005 emits warning for such shifts (guess who implemented it?) Some >other compilers emit similar warnings, too. > >Thanks, >Eugene
This page took 0 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.