[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #11 from Jakub Jelinek --- .
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #10 from Jonny Grant --- (In reply to Jonathan Wakely from comment #8) > Because 5147483647 doesn't fit in an int, so it picks a larger type, because > that's what the standard requires. 1 does fit in an int, so the compiler > picks int, because that's what the standard requires. Fair enough. Let's close this PR if no support for this suggestion.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #9 from Jonathan Wakely --- (In reply to David Brown from comment #6) > 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. ^ This.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #8 from Jonathan Wakely --- Because 5147483647 doesn't fit in an int, so it picks a larger type, because that's what the standard requires. 1 does fit in an int, so the compiler picks int, because that's what the standard requires.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #7 from Jonny Grant --- (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 size_t i = 5147483647 << 2;
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #6 from David Brown --- (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.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #5 from Jonathan Wakely --- (In reply to Xi Ruoyao from comment #3) > 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. Right. Also size_t itself might only be 32 bits, so (size_t) 1 << 32 is no better than 1 << 32. I don't think this suggestion is a good idea.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 David Brown changed: What|Removed |Added CC||david at westcontrol dot com --- Comment #4 from David Brown --- (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.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #3 from Xi Ruoyao --- (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.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #2 from Jonny Grant ---
(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.
#include
int f()
{
size_t i = 1;
i = i << 32;
return i;
}
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #1 from Xi Ruoyao --- 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.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
