Re: generic crypto - remarks

[Paul Eggert]

Jim Meyering <address@hidden> 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 <address@hidden> 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.