KKEYTE@ESOC.BITNET (Karl Keyte) (02/13/91)
How flexible are ANSI? I.e. is 'C's standardisation fixed?
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).
???richard@aiai.ed.ac.uk (Richard Tobin) (02/14/91)
In article <91042.160311KKEYTE@ESOC.BITNET> KKEYTE@ESOC.BITNET (Karl Keyte) writes: >How flexible are ANSI? I.e. is 'C's standardisation fixed? There's no chance of changing the current ANSI standard. In ten years or so, there might be another one. > struct ALIGN_TEST > { > int a at 0; > char b at 4; > float c at 8; > } You can solve this for most machines by doing something like this: struct { union {int a; char x[4];} a; union {char b; char x[4];} b; union {float c; char x[4];} c; } s; Of course, if sizeof(int) is greater than 4 you're going to lose. And you have to say s.a.a instead of s.a. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
gwyn@smoke.brl.mil (Doug Gwyn) (02/14/91)
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.
preston@LL.MIT.EDU (Steven Preston) (02/15/91)
>>>>> In article <4125@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes: > In article <91042.160311KKEYTE@ESOC.BITNET> KKEYTE@ESOC.BITNET (Karl Keyte) writes: [ stuff deleted } > You can solve this for most machines by doing something like this: > struct { > union {int a; char x[4];} a; > union {char b; char x[4];} b; > union {float c; char x[4];} c; > } s; > Of course, if sizeof(int) is greater than 4 you're going to lose. And > you have to say s.a.a instead of s.a. The original poster wanted to force certain alignments on struct elements to "provide truly portable messages on machines with different structure alignments." But, there is also the problem of big-endian vs. little-endian machines, and the issue of word size. The different representations for floating point is another problem. There is no convenient, portable way to specify a struct such that the bit pattern of struct instances can be transmitted between machines. At best you may be able to write some sort of architecture-independent ``form'' that each machine could convert to its own version of the struct (like using printf, and scanf). -- Steve Preston
KKEYTE@ESOC.BITNET (Karl Keyte) (02/16/91)
>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
gwyn@smoke.brl.mil (Doug Gwyn) (02/16/91)
In article <91045.112247KKEYTE@ESOC.BITNET> KKEYTE@ESOC.BITNET (Karl Keyte) writes: >Actually, being able to specify a structure's element alignment >DOES guarantee portability. No, I stand by what I said. While, using the technique you suggest, structure member alignment would be a NECESSARY condition for portability, it would not be SUFFICIENT. >If you know you receive an IEEE standard FP number in a particular >element then you can convert as appropriate. This has not been my experience, and it certainly does not apply to multi-byte integral types. >It's a shortfall of the standard as far as I'm concerned. You're entitled to your opinion about that. I disagree.
KKEYTE@ESOC.BITNET (Karl Keyte) (02/18/91)
>>Actually, being able to specify a structure's element alignment >>DOES guarantee portability. >No, I stand by what I said. While, using the technique you suggest, >structure member alignment would be a NECESSARY condition for >portability, it would not be SUFFICIENT. You're pre-judging here. You're making assumptions as to what kind of data is being transferred. For many applications, the alignment WOULD be adequate. It may be all bit-fields and integers. If there's a risk of byte ordering problems in integers, one single flag byte could be used to identify the scheme adopted at the source end. >>If you know you receive an IEEE standard FP number in a particular >>element then you can convert as appropriate. >This has not been my experience, and it certainly does not apply to >multi-byte integral types. The '>>' line is taken out of context! Anyway, it's true! If you transfer data according to IEEE formats, there is NO possible ambiguity even in the representation of integers - a standard is defined for that. >>It's a shortfall of the standard as far as I'm concerned. >You're entitled to your opinion about that. I disagree. Like I said, let's leave 'C' alone then. I should re-direct the discussion to the C++ forum, which is a language still undergoing evolution. Karl
gwyn@smoke.brl.mil (Doug Gwyn) (02/19/91)
In article <91049.103447KKEYTE@ESOC.BITNET> KKEYTE@ESOC.BITNET (Karl Keyte) writes: >If you transfer data according to IEEE formats, there is NO >possible ambiguity even in the representation of integers - >a standard is defined for that. While I agree that it would be useful if that aspect were standardized, in practice IT WAS NOT SPECIFIED in either ANSI/IEEE Std 754-1985 or ANSI/IEEE Std 854-1987. Indeed, section 1.3 of the latter specifically excludes "formats for internal storage of floating point numbers". I have personally encountered variations in this across nominally "IEEE floating-point" systems that I have dealt with. If it is important to you that your code work truly universally, I suggest that you consider the matter more carefully than you appear to have done so far.