From: mheaney@ni.net (Matthew Heaney)
Subject: Re: Fortran's Equivalence
Date: 1997/03/29
Date: 1997-03-29T00:00:00+00:00 [thread overview]
Message-ID: <mheaney-ya023680002903971605380001@news.ni.net> (raw)
In-Reply-To: 333840D1.7B12@cae.ca
In article <333840D1.7B12@cae.ca>, Viqar Abbasi <viqar@cae.ca> wrote:
>I have a BIT_PATTERN : System.Unsigned_32. The first 4 bits represent
>an integer A, the next 17 represent another record B, the last eleven
>represent an integer C. Ada gives something beautiful, in the "use at"
>clause, which lets me define a record to superimpose onto the bit
>pattern. The big problem with this approach is that it isn't
>guaranteed by the LRM, and I need my application to be portable to
>other Ada implementations. The Ada Quality and Style Guide, Clause
>5.9.4, also tells us that we should not use the "use at" clause to do
>such things. I am using the GNAT compiler, 3.07 on the SGI. The final
>system will be delivered for a VAX.
>
>I have started doing my mapping via "Unchecked Conversions". This seems
>to be going well, as long as I take care of the VAX/SGI bit-pattern
>differences. Would using Unchecked_Conversions, when the sizes are
>always the same, be considered 100% portable, and will work under any
>ADA implementation?
Why wouldn't it be portable? RM95 13.9 (5 - 10) list the conditions under
which the language guarantees the behavior of Unchecked_Conversion. Since
your target type is constrained, and the size of the source and target
types are the same, what's non-portable about UC?
The words about the RM recommending to not use "use at" may be referring to
the fact that that form of address overlay clause is an obsolescent feature
of the language; it was replaced by the O'Address form.
Of course, you shouldn't be using address overlays to change representation
anyway, and the RM is rightly admonishing you to not do so. That what
Unchecked_Conversion is for.
To move data - portably - from a big-endien to a little endien machine, be
sure to use the Bit_Order attribute described in RM95 13.5.3.
--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271
next prev parent reply other threads:[~1997-03-29 0:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-03-25 0:00 Fortran's Equivalence Viqar Abbasi
1997-03-26 0:00 ` Robert Dewar
1997-03-26 0:00 ` Robert A Duff
1997-03-29 0:00 ` Matthew Heaney
1997-03-29 0:00 ` Robert Dewar
1997-04-02 0:00 ` JP Thornley
1997-03-26 0:00 ` FORTRAN's Equivalence Nick Roberts
1997-03-26 0:00 ` Fortran's Equivalence Michael F Brenner
1997-03-26 0:00 ` Larry Kilgallen
1997-03-28 0:00 ` Oliver Kellogg
1997-03-29 0:00 ` Matthew Heaney
1997-03-29 0:00 ` Robert Dewar
1997-03-29 0:00 ` Robert Dewar
1997-04-01 0:00 ` Keith Thompson
1997-04-01 0:00 ` Robert Dewar
1997-04-01 0:00 ` Robert A Duff
1997-04-01 0:00 ` Robert Dewar
1997-04-04 0:00 ` Keith Thompson
1997-04-04 0:00 ` Robert Dewar
1997-04-07 0:00 ` Keith Thompson
1997-04-07 0:00 ` Charles H. Sampson
1997-04-07 0:00 ` Viqar Abbasi
1997-04-08 0:00 ` Charles H. Sampson
1997-04-08 0:00 ` Robert Dewar
[not found] ` <1997Apr15.163103.27481@nosc.mil>
1997-04-16 0:00 ` Robert Dewar
1997-04-08 0:00 ` Matthew Heaney
1997-04-09 0:00 ` Stephen Leake
1997-04-09 0:00 ` Robert Dewar
1997-04-10 0:00 ` Simon Wright
1997-04-10 0:00 ` Robert Dewar
1997-04-04 0:00 ` Keith Thompson
1997-04-04 0:00 ` Robert Dewar
1997-04-08 0:00 ` Keith Thompson
1997-04-07 0:00 ` Charles H. Sampson
1997-03-26 0:00 ` Tom Moran
1997-03-28 0:00 ` Charles H. Sampson
1997-03-29 0:00 ` Matthew Heaney
1997-04-01 0:00 ` Charles H. Sampson
1997-03-29 0:00 ` Matthew Heaney [this message]
1997-03-29 0:00 ` Robert Dewar
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox