[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #9 from Jiang An --- Additionally, what happens when I write `using my_size_t = decltype(sizeof(0));` (C++) or `typedef typeof(sizeof(0)) my_size_t;` (GNU C or C23)? I think such enhancement of warnings effectively requires size_t to be some kind of "strong typedef", and the "strength" should be generated from sizeof, alignof, etc.. Perhaps the built-in operator- between pointers also needs to generate such "strength" for the purpose of ptrdiff_t.
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 --- Comment #8 from Sam James --- FWIW, the Clang counterpart to this bug is https://github.com/llvm/llvm-project/issues/41959.
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014
Dr. David Alan Gilbert changed:
What|Removed |Added
CC||dgilbert at redhat dot com
--- Comment #7 from Dr. David Alan Gilbert ---
A similar variant is:
#include
int main(int argc, char *argv[])
{
size_t s = 42;
printf("%d\n", s);
}
t.c:7:12: warning: format ‘%d’ expects argument of type ‘int’, but argument 2
has type ‘size_t {aka long unsigned int}’ [-Wformat=]
printf("%d\n", s);
~^
%ld
I'd expect it to be suggesting %zd here.
The difference in this case is it's already generating a warning - just not the
one I'd expect (and it already knows it's size_t).
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-15 Ever confirmed|0 |1 --- Comment #6 from Martin Sebor --- Confirmed on the same basis as bug 80060.
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- T(In reply to David Malcolm from comment #4) > I wonder if it would be useful to have some kind of "-Wportability" or I've wondered about that myself. I agree that it would be useful beyond -Wformat. For -Wformat, I also agree that warning about %lu with size_t would be helpful. At the same time I suspect it would cause quite a few warnings for otherwise perfectly safe code (similar to warning for %lu with an int argument in ILP32 or %llu with a long argument in LP64).
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #4 from David Malcolm ---
I wonder if it would be useful to have some kind of "-Wportability" or
somesuch: warn about code that, although it might work OK on the user's current
configuration, would be problematic on other configurations.
This sounds useful for the end-user, but hard to implement (could be done
piecemeal, I suppose).
(and "portability" would cover a lot of aspects: 32-bit vs 64-bit, little vs
big-endian, etc etc).
What should a warning for the code in comment #0 look like?
test.c:5: format code '%lu' assumes 'unsigned long', but argument is 'size_t'
[-Wportability]
printf("got %lu\n", x);
~~^
%zu
or somesuch?
Or even, brainstorming here, give it some knowledge of other archs e.g.:
test.c:5: format code '%lu' assumes 'unsigned long', but argument is 'size_t';
this will break on NAMES_OF_ARCHS_HERE [-Wportability=i686,ppcle]
printf("got %lu\n", x);
~~^
%zu
(not sure that this last one is a good idea, but mentioning it for sake of
argument)
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 --- Comment #3 from Tom Tromey --- (In reply to jos...@codesourcery.com from comment #2) > Likewise an expression where the user did "typedef size_t my_size_t;" and > then used my_size_t. And what about expressions resulting from arithmetic > on size_t values? So it may be hard for the compiler to tell exactly what > expressions are appropriate for use with %zu (even without direct use of > __SIZE_TYPE__). I think it's still preferable for gcc to be better about this even if it can't be perfect. First, in my particular case, I think all the types in question are just "size_t" -- it's common to use this in spidermonkey. Second, the problem I have is that I wanted to enable -Wformat. So, I wrote a bunch of patches -- which then failed to build on other arches. In this case, if gcc had warned about size_t/%lu mixups in the code, while perhaps I wouldn't have caught every possible cross-arch build bug, I certainly would have far fewer of them.
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 --- Comment #2 from joseph at codesourcery dot com --- I think this is essentially the same as bug 77970 - making such warnings smarter about the case of standard typedefs. Of course an expression resulting from sizeof must be considered appropriate for %zu. Likewise _Alignof. Likewise SIZE_MAX, but headers or predefines just define it to use an appropriate constant suffix, so without looking at the macro being expanded there's nothing to distinguish it from any constant where the user wrong such a suffix directly. Likewise an expression where the user did "typedef size_t my_size_t;" and then used my_size_t. And what about expressions resulting from arithmetic on size_t values? So it may be hard for the compiler to tell exactly what expressions are appropriate for use with %zu (even without direct use of __SIZE_TYPE__).
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Since size_t is a typedef, long int might be typedef so size_t works there. I don't see a reason for a warning on those targets. Yes a warning for portability would be nice but I don't know if it is easy to do and if people want it turned on by default.
