[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-20 Ever confirmed|0 |1 Severity|normal |minor --- Comment #7 from Manuel López-Ibáñez --- (In reply to Zhendong Su from comment #4) > It would be nice to see that this gets fixed eventually [...] > it would be great to see this aspect of compilers > also gets better to become more "friendly" to beginners (and professionals > too). I think everybody working on GCC would agree with you. But the number of people working on GCC is very limited and they have a finite amount of time to dedicate to it. So either you convince new people to start working on GCC or yourself start contributing. Fixing this bug for example may be easy or may require some effort, but given that it surely affects very few people using non-standard code and there are also easy work-arounds, people already working on GCC will likely spent their time on something else. If you consider this issue important, just set-up a build environment, launch gdb and start hacking. You can grep for the error message, set a breakpoint at the error line and analyze why it is emitted and how you can modify the code to follow the warning route. If you get it fixed before the end of January, it will be in GCC 4.9. Be the change you wish to see!
[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520 --- Comment #6 from joseph at codesourcery dot com --- On Fri, 20 Dec 2013, su at cs dot ucdavis.edu wrote: > In particular, are the following well-defined according the standard or they > have undefined behavior? In both cases, you are accessing uninitialized padding bits. ISO C allows for the possibility of type punning through unions (in a footnote added in C99 TC3, not in normative text), but this is still uninitialized data. Whether accesses to uninitialized data are completely undefined behavior, or only produce unspecified values in some cases, is less clear. See N1747 and the discussion under DR 451 in the draft Chicago minutes N1764. (Your examples concern padding bits in objects with static storage duration, rather than uninitialized objects with automatic storage duration, but the issues are much the same.) The general desire is to allow optimizations that may mean an uninitialized object does not act as if it has any consistent value, without making it undefined behavior to call memcpy (for example) on objects that may be only partly initialized.
[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
> Let me raise another question that is unrelated, but perhaps you folks, in
> particular Joseph, could help add some clarify as I have been baffled by a
> couple of examples.
>
> In particular, are the following well-defined according the standard or they
> have undefined behavior?
AFAIK neither is well-defined according to base standards, in C (and C++?) the
only valid accesses to union are to the last stored field, but it is accepted
as GNU extension.
> Ex 2
>
>
> int printf (const char *, ...);
>
> struct S0
> {
> char f0;
> int f1;
> };
>
> union
> {
> int f0;
> struct S0 f1;
> } d;
>
> int
> main ()
> {
> struct S0 g = {0,0};
> d.f1 = g;
> printf ("%d\n", d.f0);
This is of course undefined behavior even with the GNU extensions, padding bits
in g are undefined and you are then accessing them. It is the same thing
as if you did struct S0 g = {0,0}; memcpy (&d.f0, &g, sizeof (int)); printf
("%d\n", d.f0);
[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
--- Comment #4 from Zhendong Su ---
Joesph and Manuel, thanks for the discussions and clarifications on the
inconsistency.
It would be nice to see that this gets fixed eventually. I remember that Peter
Norvig has commented not too long ago --- in the context of MOOCs (i.e.
massively open online classes) --- that compiler error messages are typically
very hard for beginners to make sense and scares them away from learning
programming, so it would be great to see this aspect of compilers also gets
better to become more "friendly" to beginners (and professionals too).
I also noticed the following piece of relevant GCC documentation:
http://gcc.gnu.org/onlinedocs/gcc/Warnings-and-Errors.html
The following paragraph is particularly relevant to our discussion:
"GCC always tries to compile your program if possible; it never gratuitously
rejects a program whose meaning is clear merely because (for instance) it fails
to conform to a standard. In some cases, however, the C and C++ standards
specify that certain extensions are forbidden, and a diagnostic must be issued
by a conforming compiler. The -pedantic option tells GCC to issue warnings in
such cases; -pedantic-errors says to make them errors instead. This does not
mean that all non-ISO constructs get warnings or errors."
The examples seem to fall into the category of "... whose meaning is clear ...
but merely fails to conform to the standard."
-
Let me raise another question that is unrelated, but perhaps you folks, in
particular Joseph, could help add some clarify as I have been baffled by a
couple of examples.
In particular, are the following well-defined according the standard or they
have undefined behavior?
Ex 1
int printf (const char *, ...);
union
{
int f0;
char f1;
} d;
int
main ()
{
d.f1 = 0;
printf ("%d\n", d.f0);
return 0;
}
Ex 2
int printf (const char *, ...);
struct S0
{
char f0;
int f1;
};
union
{
int f0;
struct S0 f1;
} d;
int
main ()
{
struct S0 g = {0,0};
d.f1 = g;
printf ("%d\n", d.f0);
return 0;
}
I'm quite sure that the first one is well-defined, and it's the second one that
baffles me (and GCC and Clang/LLVM behave differently on Ex 2).
Thanks for any insight.
[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520 --- Comment #3 from joseph at codesourcery dot com --- On Wed, 18 Dec 2013, manu at gcc dot gnu.org wrote: > > The main concerns for diagnostics in such cases are (a) that they are > > meaningful and (b) that invalid code gets at least one error with > > -pedantic-errors, and at least one warning or error with -pedantic. > > There may be less consistency in what's a warning / error if -pedantic > > rather than -pedantic-errors is used. > > So merely using -pedantic may produce errors that do not appear without > -pedantic? Is that really a desired behavior? Not desired, but considered less important than the main concerns for these options that I listed above.
[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to jos...@codesourcery.com from comment #1)
> The main concerns for diagnostics in such cases are (a) that they are
> meaningful and (b) that invalid code gets at least one error with
> -pedantic-errors, and at least one warning or error with -pedantic.
> There may be less consistency in what's a warning / error if -pedantic
> rather than -pedantic-errors is used.
So merely using -pedantic may produce errors that do not appear without
-pedantic? Is that really a desired behavior?
Also,
$ cc1 -std=c99 -pedantic test.c
test.c:1:5: warning: ISO C forbids zero-size array ‘a’ [-Wpedantic]
int a[0] = {};
^
test.c:1:12: warning: ISO C forbids empty initializer braces [-Wpedantic]
int a[0] = {};
^
test.c:2:11: warning: ISO C forbids empty initializer braces [-Wpedantic]
int b[] = {};
^
test.c:2:5: error: zero or negative size array ‘b’
int b[] = {};
^
test.c:3:5: warning: array ‘c’ assumed to have one element [enabled by default]
int c[];
^
Note that a[0] = {} gives a warning but "b[] = {}" gives a hard error.
Clang seems much more consistent here:
test.c:1:7: warning: zero size arrays are an extension [-Wzero-length-array]
int a[0] = {};
^
test.c:1:12: warning: use of GNU empty initializer extension
[-Wgnu-empty-initializer]
int a[0] = {};
^
test.c:2:11: warning: use of GNU empty initializer extension
[-Wgnu-empty-initializer]
int b[] = {};
^
test.c:2:11: warning: zero size arrays are an extension [-Wzero-length-array]
test.c:3:5: warning: tentative array definition assumed to have one element
int c[];
^
Note that clang gives exactly the same warning for "a[0] = {}" and "b[] = {}".
[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520 --- Comment #1 from joseph at codesourcery dot com --- The main concerns for diagnostics in such cases are (a) that they are meaningful and (b) that invalid code gets at least one error with -pedantic-errors, and at least one warning or error with -pedantic. There may be less consistency in what's a warning / error if -pedantic rather than -pedantic-errors is used.
