Jim Meyering <[EMAIL PROTECTED]> writes: > verify (offsetof (struct S, member_m) % 4 == 0); > > Hmm... that assumes 8-bit bytes.
And it also assumes no holes in integer representations. This is more portable: verify (offsetof (struct S, member_m) % alignof (uint32_t) == 0); where alignof is defined as with md5.c etc. But I agree with Bruno; it'd be better to change the type of the following member from char to uint32_t to avoid all this hassle. > Does anyone know of existing systems, less than say > 10 years old that have CHAR_BIT different from 8? They occur in the DSP world. Here is a comment about such a machine (the Texas Instruments TMS320C54x) in a GNU mailing list last year: <http://lists.gnu.org/archive/html/freetype/2004-04/msg00012.html>. That TI family is still actively developed; for example, the manual for the TMS320VC5416 is dated January 2005 (see <http://focus.ti.com/docs/prod/folders/print/tms320vc5416.html>). I expect CHAR_BIT!=8 machines will be with us for many years to come. This isn't all that relevant to coreutils, but it might be relevant for other GNU projects (e.g., GNU Radio); if it's easy to keep our code portable to DSPs we might as well do so. Bruno Haible <[EMAIL PROTECTED]> writes: > If the previous struct element is a 'uint32_t' then a struct element of > type char or char[] has the same alignment. As a pedantic point, C99 does not require that. It requires only that the following char be aligned appropriately for char, and tht it have an address greater than the uint32_t member; it does not say that there cannot be a gap between the two members. However, as a practical matter, I don't know of any implementation that has a gap there. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
