Author: Robert Hyatt
Date: 10:58:18 06/07/04
Go up one level in this thread
On June 07, 2004 at 13:13:33, Vincent Diepeveen 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. > >The result is undefined when integer = 32 bits and long long is 64 bits. > >Trivially it is a very natural thing to try to write r = 1 << 36 when using a 64 >bits type; > >Needing to cast every non-integer is not a nice way of programming now that all >processors are getting 64 bits, and 99% of all programmers will make mistakes >with it, basically taking care C/C++ in the future is not a serious programming >language. > >Because ansi-C definitely runs behind here on good programming habits, it's up >to the compilers mercy whether it works or doesn't, so only good compilers will >support it, as they support a natural way of working with the environment. > >The rule in ansi-C should read that for constants assigned, they should be >assumed to have the same type and not that they should be assumed to be integer. That won't work. i = .1 * 20.0; would produce errors if you convert .1 and 20.0 to integers first, then do the multiply. _NO_ compiler will think that 1 << 36 is anything but zero on an architecture where int == 32 bits. Making them do so would break more programs than it would help. The ANSI C standard certainly has plenty of holes. But this really isn't one of them that is a problem...
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.