Re: C-style 'union' in Ada?

["Samuel T. Harris" <u61783@gsde.hou.us.ray.com>]

Ted Dennison wrote:
> 
> In article <9li279$mhm$1@slb2.atl.mindspring.net>, Brian Catlin says...
> >
> >This is very similar to what I'm doing.  I was trying to avoid unchecked
> >conversion.  I had assumed that there would be a better way.
> 
> Well, converting between types is pretty much what Unchecked_Conversion is in
> the language for. It may look a bit ugly and scary, but that's because the
> activity you are doing is *also* a bit ugly and scary (if sometimes nessecary).
> Consider it truth in advertising. :-)
> 
> Note that since Unchecked_Conversion is a function, an assignment of the value
> will occur. That's why we usually perform it on pointers when the target data is
> large buffers.
> 

Of course, using unchecked_conversion on pointers has its own
brand of pitfalls.

Consider the Rational R1000 machines where each access type
involved very own storage pool and a pointer was actually
an offset from the base address of that storage pool.
In this environment it is meaningless to convert an access
to an 8-bit integer to an access to an 8-bit character
since the pointer of the character will dereference to a
completely different memory location.

In Ada 83, if one was assured that access types were compatible
with system.address, then access types usually used a more
conventional heap allocation and all was good with the code.

However, in Ada 95, where I can create my own storage pools,
then I may experience other problems using conversions between
pointers. The "address" of the converted pointer may resolve
to the same memory location, but is my storage pool is being
used for access to controlled types and I convert it to some access
to an non-controlled type, then my carefully construct, reference
counting, garbage collection, storage pool mechanism is inviolated.
I suppose converting a access to a non-controlled type into an
access to a controlled type involving a storage pool would be
even worse. That carefully constructed mechanism can quickly
become insane from all the "false" dereferences.

-- 
Samuel T. Harris, Senior Software Engineer II
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"