[Bug c++/92659] Suggestions for bitshift

jg at jguk dot org gcc-bugzilla@gcc.gnu.org
Tue Nov 26 15:54:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659

--- Comment #7 from Jonny Grant <jg at jguk dot org> ---
(In reply to David Brown from comment #4)
> (In reply to Jonny Grant from comment #2)
> > (In reply to Xi Ruoyao from comment #1)
> > > Is it appropriate?
> > > 
> > > Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> > > believe there is some platform where "1ull" is necessary.
> > > 
> > > Maybe I'm wrong.  But if I'm correct, suggesting "1ul" is encouraging bad
> > > code.  I'll use "(size_t) 1 << 32" for this.
> > 
> > UL means Unsigned Long, so if that type is also 64bit like size_t, then it
> > is fine.
> > 
> > 
> > I would rather use the real type, if the compiler is too stupid to start
> > with a type big enough...  the same code with 5147483647 works fine, because
> > the compiler starts with the number as a 'long int' which is already 64bit,
> > no suffix required.
> > 
> 
> I recommend you learn the details of how C works before declaring the
> compiler "stupid".  This sort of thing is not up to the compiler.  When you
> write "1 << 32", the "1" is of type "int".  The compiler is not allowed to
> choose a different type - the best it can do is give you a warning.  And the
> compiler already /does/ give a warning - a perfectly good warning.  It is
> not the compiler's job to teach you how to program in C.

Hi David,
Compiler manages it okay with this example below. Therefore the compiler
appears to be allowed to choose 'long int' for the number being shifted in this
test case.

#include <stddef.h>
size_t i = 5147483647 << 2;


More information about the Gcc-bugs mailing list