[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: generic crypto - remarks
From: |
Paul Eggert |
Subject: |
Re: generic crypto - remarks |
Date: |
Fri, 21 Oct 2005 11:14:40 -0700 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
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.