[Bug web/53608] New: Documentation could be clearer about designated initializers of unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53608
Bug #: 53608
Summary: Documentation could be clearer about designated
initializers of unions
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alan.coopersm...@oracle.com
http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html currently says:
If the same field is initialized multiple times, it will have value
from the last initialization.
(Which should probably say "the value" instead.)
Currently gcc applies this to multiple components of a union type as well.
(At least with gcc 3.4 through 4.5 here.)
For instance, this program:
#include
int main(int argc, char **argv) {
union {
struct { int i; char c[4]; } a;
struct { int i; short s[2]; } b;
} u = { .a.i = 1, .b.s[0] = 2, .b.s[1] = 3 };
printf("%d %d %d\n", u.a.i, u.b.s[0], u.b.s[1]);
}
will print "0 2 3" when compiled with gcc, since gcc appears to treat
this as two initializations of the "same field" (fields mapped to the
same spot in memory):
u.a = { 1 };
u.b = { 0, 2, 3};
and discards the first.(By comparison, the Solaris Studio compiler
prints "1 2 3" for this code.)
If the current behavior of gcc is considered correct, then it would be helpful
to update the documentation to say something like:
If the same field is initialized multiple times, or overlapping members
of the same union are initialized, the value from the last initialization
will be used.
When union members are structures, the entire structure from the last
member initialized is used. For example:
union {
struct { int i; char c[4]; } a;
struct { int i; short s[2]; } b;
} u = { .a.i = 1, .b.s[0] = 2, .b.s[1] = 3 };
is equivalent to:
union {
struct { int i; char c[4]; } a;
struct { int i; short s[2]; } b;
} u = { .a = { 1 }, .b = { 0, 2, 3 } };
which is in turn equivalent to:
union {
struct { int i; char c[4]; } a;
struct { int i; short s[2]; } b;
} u = { .b = { 0, 2, 3 } };
[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025 Alan Coopersmith changed: What|Removed |Added CC||alan.coopersmith at oracle dot com ||, ||ro at CeBiTec dot Uni-Bielefeld.DE --- Comment #7 from Alan Coopersmith --- This seems to go back to: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a6905708d86d6c2d8560168ac5accb816a2038c8 and was probably to deal with the bit of the Solaris system headers in various releases that throws an error if you try to define _XOPEN_SOURCE to 600 or 700 and didn't have a __STDC_VERSION__ matching C99 defined.
[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025 --- Comment #9 from Alan Coopersmith --- And I got here this week due to the discussion on https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2258/diffs?commit_id=78cd9c60eef40650bba1182d8bb51fc9beb938e2#note_254374 about why Mesa needed to check for _cplusplus and not just __STDC_VERSION__ when deciding whether or not to use the "restrict" keyword. I too fear you'll be carrying this code for a while - even in the latest patches, Solaris 10 has in the header: #if __STDC_VERSION__ - 0 >= 199901L #define _STDC_C99 #endif [...] #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ and pre-2001 POSIX applications" #elif !defined(_STDC_C99) && \ (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications \ require the use of c99" #endif That's also in the initial release of Solaris 11.3 - you either need to have Solaris 11.3 support updates or to upgrade to Solaris 11.4 to get a version of without that check.
[Bug c/114776] New: -Wuse-after-free analysis believes assert() but not g_assert_null()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776 Bug ID: 114776 Summary: -Wuse-after-free analysis believes assert() but not g_assert_null() Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: alan.coopersmith at oracle dot com Target Milestone: --- Created attachment 57985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57985&action=edit Test case When reviewing the -Wuse-after-free error reported in: https://gitlab.freedesktop.org/xorg/lib/libxmu/-/merge_requests/13 in which gcc gives a use-after-free warning for p in: p2 = Xmureallocarray(p, 2, ALLOC_LIMIT); g_assert_null(p2); [...] free(p); even though the realloc failed and returned NULL and did not free p. I found that the -Wuse-after-free warning went away if I changed g_assert_null(p2); to assert(p2 == NULL); so it appears something in the way g_assert_null from glib is defined does not convince gcc that p2 must be NULL the way the simple system assert does. I've made a cut down test case, and can reproduce the false alarm with gcc `pkg-config --cflags glib-2.0` -Wall -O2 -c realloc.c using gcc 13.2.0 on Solaris 11.4.66 on x86-64. (The original report came from a gentoo Linux user, and I reproduced on Debian Linux, so this isn't OS-specific.) Adding -DUSE_SYSTEM_ASSERT to the compiler command line makes the warning go away.
[Bug tree-optimization/114776] -Wuse-after-free analysis believes assert() but not g_assert_null()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776 --- Comment #5 from Alan Coopersmith --- Created attachment 57986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57986&action=edit Preproccessed test case
[Bug tree-optimization/114776] -Wuse-after-free analysis believes assert() but not g_assert_null()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776 --- Comment #6 from Alan Coopersmith --- Thanks, I didn't realize there was a test_nonfatal_assertions path through the g_assert that could return here. I'll update the wording on my proposed workaround to reflect that: https://gitlab.freedesktop.org/xorg/lib/libxmu/-/merge_requests/16
[Bug analyzer/113329] analyzer: False positive analyzer-fd-use-without-check with dup2()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113329 Alan Coopersmith changed: What|Removed |Added CC||alan.coopersmith at oracle dot com --- Comment #1 from Alan Coopersmith --- Created attachment 58057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58057&action=edit dup2.c test case
[Bug analyzer/113329] analyzer: False positive analyzer-fd-use-without-check with dup2()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113329
--- Comment #2 from Alan Coopersmith ---
I've hit this as well with gcc 13.2 when building xfs with -fanalyzer.
I extracted this test case from
https://gitlab.freedesktop.org/xorg/app/xfs/-/blob/master/os/daemon.c
and when built with "gcc -fanalyzer -c dup2.c" it reports:
dup2.c: In function ‘DetachStdio’:
dup2.c:23:13: warning: ‘dup2’ on possibly invalid file descriptor ‘0’
[-Wanalyzer-fd-use-without-check]
23 | if (dup2(nullfd, 0) == -1) {
| ^~~
‘DetachStdio’: events 1-6
|
| 10 | close (0);
| | ^
| | |
| | (1) closed here
|..
| 18 | if (nullfd == -1) {
| |~
| ||
| |(2) following ‘false’ branch (when ‘nullfd != -1’)...
|..
| 22 | if (nullfd != 0) {
| |~
| ||
| |(3) ...to here
| |(4) following ‘true’ branch (when ‘nullfd != 0’)...
| 23 | if (dup2(nullfd, 0) == -1) {
| | ~~~
| | |
| | (5) ...to here
| | (6) ‘0’ could be invalid
|
[Bug analyzer/114880] New: analyzer: False positive Wanalyzer-fd-use-after-close when open returns the same fd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114880
Bug ID: 114880
Summary: analyzer: False positive Wanalyzer-fd-use-after-close
when open returns the same fd
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: alan.coopersmith at oracle dot com
Target Milestone: ---
Created attachment 58058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58058&action=edit
dup2.c test case
I've hit this originally with gcc 13.2 when building xfs with -fanalyzer.
I extracted this simplified test case from
https://gitlab.freedesktop.org/xorg/app/xfs/-/blob/master/os/daemon.c
and when built with "gcc -fanalyzer -c dup2.c" it reports:
dup2.c:30:9: warning: ‘dup2’ on closed file descriptor ‘0’
[-Wanalyzer-fd-use-after-close]
30 | if (dup2 (0, 1) == -1) {
| ^~~
‘DetachStdio’: events 1-6
|
| 10 | close (0);
| | ^
| | |
| | (1) closed here
|..
| 18 | if (nullfd == -1) {
| |~
| ||
| |(2) following ‘false’ branch (when ‘nullfd != -1’)...
|..
| 22 | if (nullfd != 0) {
| |~
| ||
| |(3) ...to here
| |(4) following ‘false’ branch (when ‘nullfd == 0’)...
|..
| 30 | if (dup2 (0, 1) == -1) {
| | ~~~
| | |
| | (5) ...to here
| | (6) ‘dup2’ on closed file descriptor ‘0’; ‘close’ was at
(1)
|
dup2.c:34:9: warning: ‘dup2’ on closed file descriptor ‘0’
[-Wanalyzer-fd-use-after-close]
34 | if (dup2 (0, 2) == -1) {
| ^~~
‘DetachStdio’: events 1-8
|
| 10 | close (0);
| | ^
| | |
| | (1) closed here
|..
| 18 | if (nullfd == -1) {
| |~
| ||
| |(2) following ‘false’ branch (when ‘nullfd != -1’)...
|..
| 22 | if (nullfd != 0) {
| |~
| ||
| |(3) ...to here
| |(4) following ‘false’ branch (when ‘nullfd == 0’)...
|..
| 30 | if (dup2 (0, 1) == -1) {
| |
| |||
| ||(5) ...to here
| |(6) following ‘false’ branch...
|..
| 34 | if (dup2 (0, 2) == -1) {
| | ~~~
| | |
| | (7) ...to here
| | (8) ‘dup2’ on closed file descriptor ‘0’; ‘close’ was at
(1)
|
But in both these cases if it followed the ‘nullfd == 0’ path as it claims,
then 0 is a valid fd returned from "nullfd = open ("/dev/null", O_RDWR);"
(This test case also returns other false positives, covered by other bugs
such as bug 113329.)
[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025 Alan Coopersmith changed: What|Removed |Added CC||alan.coopersmith at oracle dot com --- Comment #11 from Alan Coopersmith --- While Solaris 11.3 support has been dropped from gcc now, Jonathan Perkins from pkgsrc found that just removing the definition of __STDC_VERSION__ didn't work with some of the illumos headers: https://github.com/jperkin/notes/blob/main/gcc-cpp-stdc/README.md
