[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug default/24430] New: reader: fold away const for array types
https://sourceware.org/bugzilla/show_bug.cgi?id=24430
Bug ID: 24430
Summary: reader: fold away const for array types
Product: libabigail
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: default
Assignee: dodji at redhat dot com
Reporter: maennich at google dot com
CC: libabigail at sourceware dot org
Target Milestone: ---
Created attachment 11727
--> https://sourceware.org/bugzilla/attachment.cgi?id=11727&action=edit
test.c
Given the following example:
struct test {
const char asdf[4];
};
void func(struct test arg) {}
The C standard seems to allow two representations for 'asdf' here:
const char[] and const char[] const
"If the specification of an array type includes any type qualifiers,
the element type is so-qualified, not the array type."
In fact, clang and gcc seem to disagree here as well and produce the following
dwarf info:
clang: asdf -> array_type -> const_type -> signed char
gcc: asdf -> const_type -> array_type -> const_type -> signed char
That upsets libabigail when comparing the ABI of two sample builds:
1 function with some indirect sub-type change:
[C]'function void func(test)' at test.c:5:1 has some indirect sub-type
changes:
parameter 1 of type 'struct test' has sub-type changes:
type size hasn't changed
1 data member change:
type of 'const char test::asdf[4]' changed:
entity changed from 'const char[4]' to 'const char[4] const'
Reproducer:
$ clang-7 -g -gdwarf-2 -shared test.c -o clang.out
$ gcc -g -gdwarf-2 -shared test.c -o gcc.out
$ abidiff clang.out gcc.out
I attach a set of binaries.
--
You are receiving this mail because:
You are on the CC list for the bug.