Author: Omid David Tabibi
Date: 04:06:22 02/09/04
Go up one level in this thread
On February 08, 2004 at 17:18:28, Dieter Buerssner wrote: >On February 08, 2004 at 16:49:24, Omid David Tabibi wrote: > >>On February 08, 2004 at 13:22:38, Dieter Buerssner wrote: >>>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. > >I don't see, what using a typedefed UINT32 buys you here. If you need to convert >a string to an UINT32 with (say) sscanf, which format specifier do you use? %u? >%lu? Or even some #define format specifier? It makes the code look horrible >(IMHO) > >#define UINT32_CONV_SPEC "%u" > > UINT32 a; > int i, j; > sscanf(buf, "%d" UINT32_CONV_SPEC "%d", &i, &a, &j); > >Many similar problems. > >Do you write > > UINT32 x = 1<<23; > >or > > UINT32 x = (UINT32)1<<23; > >or > > UINT32 x = 1UL<<23; > >If you are aware of these things already, you won't make the bug, that started >this discussion. > >I don't see any advantage of using a typeded type (in the context of this >discussion - of course there are certainly places for it). For example in attack tables I need a 32 bit variable, not more, not less. So I use a UINT32 that guarantees that the variable is 32 bit. The advantage is not backward compatibility, but forward compatibility. Suppose that in the future type int is considered 64 bit (very probable, int was 16 bit on 16 bit machines, 32 bit on 32 bit machines, why not 64 bit on 64 bit machines?). My UINT32 will still work there without any problem. On a 16 bit system the following will result in the same bug: UINT32 a = 1 << 20; But I assume that we are already past 16 bit systems. Maybe not an accurate assumption, but surely a very convenient one :) But 64 bit is far from standard yet. Back to the original problem of unsigned __int64 a = 1 << 50; Any decent compiler must display a warning here. It is not important how it deals with this undefined behavior, as long as it does display the warning. >If I need a typical >unsigned variable, where 16 bit may not enough, but 32 bit is, I use unsigned >long (normally). If it is an array, and space might be an issue, I used typedefs >(I worked in environments with 64 bit longs). By default (no considerations for >speed/space - just get a correct program) I use the "normal" types (assuming int >is at least but not necessarily more than 16 bits, long 32 bits). > >Some functions of the Standard C library really need type long, and not any >typedefed type. For example fseek. In those cases I do use long, just for calling those functions (many Windows API functions also need long). But I don't use long for my own code. > >Regards, >Dieter
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.