Re: [patch] limit and document unnamed fields.

[DJ Delorie <dj at redhat dot com>]

> You were also addressing the lack of documentation and testcases for this
> feature - which means that considering the precise definition of the
> feature is appropriate at this point.  (Documentation should be clear
> about exactly what is allowed, but if we might want to disallow examples
> such as the above (or more complicated cases, e.g. struct s { struct { int
> a; struct { int b; }; }; struct { int b; }; };) we shouldn't document them
> as allowed now and disallow them later.)

I got distracted, but I'm thinking about this again.  I can easily
update the documentation to say "don't do that" but updating gcc to
detect such ambiguous cases is more difficult (it's recursive).

GCC currently treats fields in unnamed structs similar to a scoping
issue - it uses the field closest to the scope it's looking at, and
silently ignores less direct fields that could match.  If this
behavior is well defined, we can document it as such.  Or, we can say
that behavior is undefined in such cases.  If gcc doesn't warn or fail
such cases, should we document that fact and/or document that it may
fail in the future, or have the documentation describe current
practice and leave it at that?

Personally, I'd like to update the documentation to say "undefined,
may be a fatal error in the future." and leave gcc as-is (aside from
the patch already submitted).

As for whether the gcc patch should go in grokfield, rather than
finish_struct, I can go either way but trapping it at the source seems
more straightforward than waiting until later and having to hunt it
down again.


struct {
  int x;
  struct { int x; };
} a;