Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!psuvax1!psuvm!esoc!kkeyte
From: KKEYTE@ESOC.BITNET (Karl Keyte)
Newsgroups: comp.std.c
Subject: Re: Representation Clauses
Message-ID: <91045.112247KKEYTE@ESOC.BITNET>
Date: 15 Feb 91 16:03:47 GMT
References: <91042.160311KKEYTE@ESOC.BITNET> <15187@smoke.brl.mil>
Lines: 51
Organisation: European Space Operation Centre (E.S.O.C)

>In article <91042.160311KKEYTE@ESOC.BITNET> KKEYTE@ESOC.BITNET (Karl Keyte)
>writes:
>>How flexible are ANSI?  I.e. is 'C's standardisation fixed?
>
>Yes, the standard was approved by ANSI in late 1989 and is not
>expected to undergo revision (apart from possible ISO addenda,
>which are not attempting to make changes of the sort that you
>suggest) for several years to come.
>
>>I feel that 'C' is missing data alignment representation clauses in
>>structures.  I would like to be able to do something like:
>>  struct ALIGN_TEST
>>  {
>>     int       a      at 0;
>>     char      b      at 4;
>>     float     c      at 8;
>>  }
>>in order to force the offset of the elements.  This then enables
>>structures to provide truly portable messages on machines with
>>different structure alignments.  For example, the above structure
>>is not the same on a Sun-3 and a Sun-4 (Sparc).
>
>Ideas along these lines were submitted during preparation of the
>ANSI C standard, and were rejected by the committee.  There are
>at least two significant problems with the idea, one being that
>it is an innovation, not existing practice, the other being that
>it doesn't provide the portable message structure that you think
>it does.  You can insert padding by use of dummy fields, but the
>most difficult issues for binary data interchange between
>heterogeneous architectures are much deeper than mere alignment
>of fields.  Sun invented the XDR protocols to deal with them, for
>one concrete example worthy of study.

Actually, being able to specify a structure's element alignment
DOES guarantee portability.  This is why it was introduced to
Ada which can even align elements on bit boundaries.  Practices
such as Sun's XDR have got nothing to do with what I'm talking
about; they concern themselves with actual representation of
the DATA, not it's alignment/positioning.  If you know you
receive an IEEE standard FP number in a particular element then
you can convert as appropriate.  If you can't be sure where the
element is then you're lost.

Of course, such an implementation would have run-time efficiency
implications, but only if user-forced alignment was bad.  In general,
putting the most restrictive data types first will implicity force
good alignment, but it is no guarantee.

It's a shortfall of the standard as far as I'm concerned.

Karl