[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.