🚀 go-pugleaf

pontius@twonky.btv.ibm.com (Dale Pontius) wrote:
>
>In article <43bdus$l2g@nntp.nta.no>, ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) writes:
>>
>> What worries me is that there does not seem to be a clean way to ensure that a
>> record has a specific *physical* layout. If it is to be used for systems
>> programming, I think this is an important feature, because there is often a need
>> to interface to devices which expect to use a fixed data format.
>>
>One of my pet peeves, too. It isn't just for systems programming, either.
>Often you have to work with 'legacy' data constructs, and need to utilize
>the detail bit-and-byte layout.

On our Ada projects at NASA, we have been successful in using Ada records to
represent the data and using representation clauses (see chapter 13, Ada
Reference Manual) to describe the physical layout.  Of course, that didn't
solve the problem of our FORTRAN systems writing REAL*8 variables as VAX 
D_FLOATING and Ada code expecting G_FLOATING data. :)
>
>For some reason, portability has come to mean, "Hide all knowledge of the
>bit-and-byte level." This is a bit of a fallacy, as you are really trying
>to hide the effects of the machine archtecture. Bits-and-bytes are really
>abstract concepts, independent of architecture, and shouldn't be hidden.
>Probably it most hits the road when you consider element alignment within
>a structure. Even there you probably want and need to know such things
>for performance reasons, as well as be able to read structures that are
>stored in binary form in files.

I agree that the above definition of portability is a fallacy, and that any
self-respecting program language should have something like Ada 
representation clauses to allow definition of physical layouts.

Mike
Definitely not speaking for any level of NASA management
>
>Dale Pontius
>(NOT speaking for IBM)