On Thu, 01 Feb 2007 12:12:00 -0800, Luigi Rizzo <[EMAIL PROTECTED]> wrote:
> one reason of concern is a note about future support that i misread > in http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html: > > ... For example, this structure: > ... > It is ambiguous which a is being referred to with `foo.a'. > Such constructs are not supported and must be avoided. In > the future, such constructs may be detected and treated as > compilation errors. > > maybe the note on treating these as errors in the future > refers only to ambiguous constructs and not to all unnamed unions. Yes, indeed. In our case there is no ambiguity. The whole struct becomes much easier to read if the unions are anonymous. > the other reason for concern is ease of porting to other systems -- > things like pragmas and attributes are easy to remap with a one time > #define, but unnamed extensions are a pain to handle because you > have to modify all references to the fields in the source. > > and of course - there is the issue of code safety, because > 1)this feature can cause ambiguous constructs, and 2) it doesn't > suggest the programmer that multiple items are sharing the same > memory location. The union name at least gives you some hints, > especially if you call it 'u' ... I somewhat agree with the portability part. However, these Linux system structures (they're part of V4L2 and, therefore, the official Linux kernel) are not designed to be portable. And given the wide availability of gcc I think you'd have a hard time finding a platform to port V4L2 to that doesn't support these constructs. If you want, you can raise the discussion on the V4L2 mailing list. When we proposed the changes we were really just trying to fit in to what was already there. Cheers, Martin _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
