Re: sizeof wrong for struct with final zero-length array

[Greg McGary <greg at mcgary dot org>]

"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

> > The following testcases fail:
> 
> Thanks for your bug report. I believe the error is in the test cases,
> not in gcc.

OK.

> The specific case of a structure containing *only* a flexible array
> member is not supported in C99, however, I believe that your point
> applies to all other cases as well, right?

Yes.

> So in a sizeof expression, the size of the object never matters; it is
> always the size of the type that counts, and for a structure with a
> FAM, the size of the array does not matter (only the alignment of the
> array type may matter).

OK.  My sizeof questions were just prologue to the issue that matters
to me, which is debug information for FAMs.

Observe the FAM `values' here:

(gdb) p _nl_C_LC_NUMERIC
$1 = {
  name = 0x400fc8c5 "C", 
  filedata = 0x0, 
  filesize = 0, 
  mmaped = 0, 
  usage_count = 4294967295, 
  nstrings = 3, 
  values = 0x40106b80
}

`values' prints as the address of the FAM, not as its contents, since
the debug information gives the FAM's size as 0 so gdb can do no
better.  It would be more useful to automatically print `values'
within the `p _nl_C_LC_NUMERIC' like so:

(gdb) p *_nl_C_LC_NUMERIC.values@3
$6 = {{
    wstr = 0x400fb9c3, 
    string = 0x400fb9c3 ".", 
    word = 1074772419
  }, {
    wstr = 0x400fb9c2, 
    string = 0x400fb9c2 "", 
    word = 1074772418
  }, {
    wstr = 0x400fb9c0, 
    string = 0x400fb9c0 "\177", 
    word = 1074772416
  }}

I order to support this feature, gcc needs to output debug symbol
table entries that reflect the decl, rather than the type.  Debug
information is beyond the scope of the C standard, and the STABS
documentation at least doesn't address this case, so it would seem
there is some freedom to implement the treatment of FAMs I describe.

Comments?

Greg