https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107100
--- Comment #1 from Eric Blake ---
Might be a dup of bug#101648
: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eblake at redhat dot com
Target Milestone: ---
I'm at a loss for why disabling -O2
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eblake at redhat dot com
Target Milestone: ---
Right now, -Woverride-init is so strong that it interferes with the use of
gcc's extension of ranged-array initializer syntax as a common way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
--- Comment #1 from Eric Blake ---
Other references to compound initializers going out of scope and causing
problems:
https://stackoverflow.com/questions/47691857/lifetime-of-a-compound-literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270
--- Comment #5 from Eric Blake ---
For what it's worth, POSIX requires syslog() to support %m, and this is the
case even on BSD systems. So a new __attribute__((format(syslog, x, y)))
archetype would be an easy way of at least notating functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270
--- Comment #3 from Eric Blake ---
Confirmed that -Wpendantic flags %m:
$ gcc -Wpedantic -Wformat foo.c -o foo
foo.c: In function ‘main’:
foo.c:3:10: warning: ISO C does not support the ‘%m’ gnu_printf format
[-Wformat=]
printf("%m %B\n");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270
--- Comment #1 from Eric Blake ---
Note that gcc -Wformat DOES flag things like printf("%B"), %m is the only
special-case where it is not flagged even on systems where it does not work,
and where we'd want fine-tuned control over whether a
Assignee: unassigned at gcc dot gnu.org
Reporter: eblake at redhat dot com
Target Milestone: ---
I was working porting a project originally written for Linux over to BSD
systems, and had to fix code that called printf("%m") to spell out longhand
printf("%s", strerro
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eblake at redhat dot com
Target Milestone: ---
When porting from one machine to another, especially when porting from 32-bit
to 64-bit software, getting warnings about mismatches such as printf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #15 from Eric Blake ---
(In reply to Martin Sebor from comment #14)
> I would suggest to keep the warning simple and avoid overdesigning it with
> workarounds for this case. The solution in comment #12 (copied below) seems
> like a
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eblake at redhat dot com
Target Milestone: ---
POSIX says that EAGAIN and EWOULDBLOCK may be identical, but also that they may
be distinct. Therefore, well-written portable code MUST check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446
Eric Blake eblake at redhat dot com changed:
What|Removed |Added
CC||eblake at redhat
Assignee: unassigned at gcc dot gnu.org
Reporter: eblake at redhat dot com
Target Milestone: ---
The standard is clear that enums have implementation-defined signedness (C99
6.7.2.2P4 Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446
--- Comment #3 from Eric Blake eblake at redhat dot com ---
see also bug 66249 where the implementation-defined signedness of enums comes
into play, and where I argue that neither %d nor %u should warn when an enum
type is passed through varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60194
Eric Blake eblake at redhat dot com changed:
What|Removed |Added
CC||eblake at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446
--- Comment #4 from Eric Blake eblake at redhat dot com ---
Arguably, %u with short should warn, while %hu with short should not. On
the other hand, if I use %hu with int, it is unclear to me whether I should
get a warning (the fact that I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488
--- Comment #3 from Eric Blake eblake at redhat dot com ---
Since the engine is able to warn at -O0 when I _don't_ take the address, I
don't see why the warning is lost by the mere action of taking the address.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eblake at redhat dot com
Here's a simple example of where -Wuninitialized is rather useless at default
optimization:
$ cat foo.c
#include stdlib.h
int main(void) {
char *oops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57475
--- Comment #3 from Eric Blake eblake at redhat dot com ---
(In reply to Manuel López-Ibáñez from comment #1)
We could detect the special case where the spelling is the same and report
where each type is declared.
Be aware that spelled the same
19 matches
Mail list logo
