https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #6 from David Brown <david at westcontrol dot com> --- (In reply to Xi Ruoyao from comment #3) > (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. > > That is true on *your platform*. > > I can't find any specification in C standard saying "the bitwidth of long > should >= the bitwidth of size_t". So at least theoretically it may be > insufficient. > > Writing unportable thing is OK (if you don't care about other platforms) but > *suggesting* unportable thing is bad. There is no requirement for "size_t" to be of any particular size in relation to the other integer types. On 64-bit Windows, for example, size_t is 64 bits but unsigned long is 32 bits. So there is no portable integer constant suffix that would suit for "size_t". However, the "size_t" here is a red herring - the problem is that the expression "1 << 32" overflows, but it would not overflow if the "1" was of a 64 bit type. The most portable choice here would be "1ull" or "1ll" (the compiler has no way to guess which you want). But that would not work with pre-C99 standards. All in all, the whole idea sounds counter-productive to me. If you need spoon-feeding about the details of C here, you would be better off reading a book on the language than using trial and error and guessing from compiler messages. And if you don't need spoon-feeding but just made a little mistake in your code (as we all do on occasion), then the current warning is fine.
