From: "Bob Proulx" <[EMAIL PROTECTED]>
> > From: "Jim Meyering" <[EMAIL PROTECTED]>
> >
> > > +/* Ensure that for each member of `enum size_spec' there is an
> > > + initializer in the width_bytes array. */
> > > +struct assert_width_bytes_matches_size_spec_decl
> > > +{
> > > + int t1[sizeof width_bytes / sizeof width_bytes[0] - N_SIZE_SPECS];
> > > + int t2[N_SIZE_SPECS - sizeof width_bytes / sizeof width_bytes[0]];
> > > +};
> > > +
> >
> > I like the idea of verifying that the code is consistent. But the above
> > structure assumes that zero-length arrays are valid, and they are not in
> > standard C (at least not in C90, I suppose C99 could have added that?).
>
> I am slipping into this discussion late but I think a misunderstanding
> exists. width_bytes[0] is the first element of the array, which is
perfectly
> valid.
I agree.
> sizeof width_bytes[0] is the number of bytes of the first element of the
> array. That should always be non-zero.
I also agree here.
> I don't see where the compiler is seeing a zero sized array for this.
I was referring to the size of t1 and t2. "sizeof width_bytes/sizeof
width_bytes[0]" is of course the number of elements in the width_bytes
array. N_SIZE_SPEC is the number of elements in the size_spec array. If
those two values are equal, which they are supposed to be, then the above
declaration makes both t1 and t2 have a length of zero.
I have verified that MS Visual C++ 6.0 produces an error when given the
above code. I also verified that gcc 2.95.2 accepts it without any
warnings, but does produce a warning for it if given the "-pedantic" flag.
> > As an alternative, you could have an N_WIDTH_BYTES entry at the end of
the
> > width_bytes array, and then have something like:
> >
> > #if N_SIZE_SPECS != N_WIDTH_BYTES
> > #error Array size mismatch
> > #endif
To force the two arrays to have the same size, I find the above #if
statement much more straightforward than the
structure-with-zero-length-arrays anyway.
--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-335-2495 Tel
_______________________________________________
Bug-textutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-textutils
