comp.lang.ada
 help / color / mirror / Atom feed
* Ada 83 Pointers question
@ 1999-01-20  0:00 Lowe Anthony A
  1999-01-21  0:00 ` robert_dewar
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Lowe Anthony A @ 1999-01-20  0:00 UTC (permalink / raw)


We are using a supped up 83 compiler originally DDC-I but maintained
internally with several cool Ada 95 features added on.  To this point we
have been testing on NT using ObjectAda (95 not 83), but we just moved
to the 83 compiler and a data structure which was working fine, no
longer even elaborates.

The basic idea is we have a series of data (an array) which holds a
bunch of information (a record) which contains a boolean (among other
items).   This is great for large data storage, but we need a 'snapshot'
of this data which is created using an array of another record which has
a boolean pointer into the original array.  This 'snapshot' is a
constant instance of an unconstrained array type.

Now since we are safety critical, we have been forbidden from using a
new clause and since the 'Access does not exist yet, the engineer
created a unchecked conversion to go between a System.Address and a
boolean pointer.   Thus when the 'snapshot' is created, it then
references the boolean pointer element to the array of the record to the
'Address of the boolean component.  Whew!

Now I am not completely comfortable with all of the aspects of this
design, and there are many spots for the compiler to fail, but someone
in our organization said that Ada 83 has a limitation that a pointer can
not point to an item in a composite type.  This seems a bit broad.  If
the answer is 'you can not trust the unchecked conversion to a pointer'
or 'you can not trust the compiler to represent the data the same way
every time for the 'Address to be valid' or 'maybe the compiler can not
handle the unconstrained array' or a dozen others I am hoping to hear
than fine.  I just want to make sure though that we are not fighting
against a true language limitation/bug which we can not solve.

Any suggestions/ background / input / hints / comments / pondering /
posturing / opinions are welcome but please don't lambaste the approach
too much.  We have some pretty severe limitations and it is a young guy
with large dreams and grand notions.  Thanks in advance!

--
Tony Lowe                   Rockwell Collins
1431 Opus Place   -  Downers Grove, IL 60515
(630)-960-8603          Fax : (630)-960-8207






^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ada 83 Pointers question
  1999-01-20  0:00 Ada 83 Pointers question Lowe Anthony A
  1999-01-21  0:00 ` robert_dewar
@ 1999-01-21  0:00 ` dennison
  1999-01-21  0:00 ` Jeff Carter
  2 siblings, 0 replies; 6+ messages in thread
From: dennison @ 1999-01-21  0:00 UTC (permalink / raw)


In article <36A658CA.97438B6@cacd.rockwell.com>,
  aalowe@cacd.rockwell.com wrote:
> We are using a supped up 83 compiler originally DDC-I but maintained
...
> Now I am not completely comfortable with all of the aspects of this
> design, and there are many spots for the compiler to fail, but someone
> in our organization said that Ada 83 has a limitation that a pointer can
> not point to an item in a composite type.  This seems a bit broad.  If

Well, in Ada83 the only language-defined way to get a vaild pointer was to
use an allocator. Unchecked conversion from address to pointer types was not
gauranteed to work. It would be physically impossible to manage to allocate
yourself a pointer to a record field or array element (other than the first
one, of course). However in practice every vendor gave you a way to get such
pointers, usually through converting addresses to access types.

There is also the issue of placement. You can't just add 20 to the address of
an array of enums and expect that to give you elment 20 in the array. You
must first take steps to ensure that the enums are represented as bytes, and
the array is packed to the expected size. Likewise you have no clue what the
offset of a field in a record is from the start of the record unless you
specifiy it with a representation clause. But taking the 'address of the
field or element in question will typically get around this issue.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ada 83 Pointers question
  1999-01-20  0:00 Ada 83 Pointers question Lowe Anthony A
@ 1999-01-21  0:00 ` robert_dewar
  1999-01-21  0:00   ` dennison
  1999-01-21  0:00 ` dennison
  1999-01-21  0:00 ` Jeff Carter
  2 siblings, 1 reply; 6+ messages in thread
From: robert_dewar @ 1999-01-21  0:00 UTC (permalink / raw)


In article <36A658CA.97438B6@cacd.rockwell.com>,
  aalowe@cacd.rockwell.com wrote:
> Now since we are safety critical, we have been forbidden
> from using a new clause and since the 'Access does not
> exist yet, the engineer created a unchecked conversion to
> go between a System.Address and a boolean pointer.   Thus
> when the 'snapshot' is created, it then references the
> boolean pointer element to the array of the record to the
> 'Address of the boolean component.  Whew!

I am having trouble understanding the above paragraph. As
best I understand it, it says

"Since we are safety critical, we have been forbidden from
doing this in the safe and reliable way, and have instead
rigged up a highly non-portable unsafe way of doing things
that may or may not work, but it seems to work OK, so we
guess it's OK, though it leaves us feeling uncomfortable".

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ada 83 Pointers question
  1999-01-20  0:00 Ada 83 Pointers question Lowe Anthony A
  1999-01-21  0:00 ` robert_dewar
  1999-01-21  0:00 ` dennison
@ 1999-01-21  0:00 ` Jeff Carter
  1999-01-21  0:00   ` Matthew Heaney
  2 siblings, 1 reply; 6+ messages in thread
From: Jeff Carter @ 1999-01-21  0:00 UTC (permalink / raw)


"Lowe Anthony A" asked about using Unchecked_Conversion to obtain an
access value to a component of a record that is a component of an array.

It is true that an Ada-83 access value cannot refer to anything except
the result of "new" under normal circumstances. However, unchecked
features of the language explicitly bypass the normal checks of the
language and let you do things that might be dangerous, including this.

It is perfectly legal Ada 83 to instantiate Unchecked_Conversion to
convert from System.Address to an access type. If the result designates
the value you want it to, then this should work fine for you. However,
such an approach is entirely compiler dependent. This may not bother
you, since you are maintaining the compiler.

I cannot tell what is causing your constant array declaration to fail to
elaborate without more specific information. The use of
Unchecked_Conversion does not sound as if it is causing this, however.

-- 
Jeff Carter
E-mail: carter commercial-at innocon [period | full stop] com
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ada 83 Pointers question
  1999-01-21  0:00 ` Jeff Carter
@ 1999-01-21  0:00   ` Matthew Heaney
  0 siblings, 0 replies; 6+ messages in thread
From: Matthew Heaney @ 1999-01-21  0:00 UTC (permalink / raw)


Jeff Carter <spam.carter.not@spam.innocon.com> writes:

> It is perfectly legal Ada 83 to instantiate Unchecked_Conversion to
> convert from System.Address to an access type.

That's being _very_ generous...

> If the result designates the value you want it to, then this should
> work fine for you. However, such an approach is entirely compiler
> dependent. This may not bother you, since you are maintaining the
> compiler.

The issue is whether or not pointers to unconstrained arrays use a dope
vector or not, and whether the pointer points to the dope vector, or to
the array itself.

In general, if you convert from System.Address to an access type, you
better know what you are doing!





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ada 83 Pointers question
  1999-01-21  0:00 ` robert_dewar
@ 1999-01-21  0:00   ` dennison
  0 siblings, 0 replies; 6+ messages in thread
From: dennison @ 1999-01-21  0:00 UTC (permalink / raw)


In article <787fcm$k03$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <36A658CA.97438B6@cacd.rockwell.com>,
>   aalowe@cacd.rockwell.com wrote:
> > Now since we are safety critical, we have been forbidden
> > from using a new clause and since the 'Access does not
> > exist yet, the engineer created a unchecked conversion to
> > go between a System.Address and a boolean pointer.   Thus
> > when the 'snapshot' is created, it then references the
> > boolean pointer element to the array of the record to the
> > 'Address of the boolean component.  Whew!
>
> "Since we are safety critical, we have been forbidden from
> doing this in the safe and reliable way, and have instead
> rigged up a highly non-portable unsafe way of doing things
> that may or may not work, but it seems to work OK, so we
> guess it's OK, though it leaves us feeling uncomfortable".

That's a good point. Take a close look at the actual requirements you have.
Its possible that only UNCHECKED_DEALLOCATION is prohibited. That would make
allocators just fine, as long as you only use a limited amount of them.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~1999-01-21  0:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-01-20  0:00 Ada 83 Pointers question Lowe Anthony A
1999-01-21  0:00 ` robert_dewar
1999-01-21  0:00   ` dennison
1999-01-21  0:00 ` dennison
1999-01-21  0:00 ` Jeff Carter
1999-01-21  0:00   ` Matthew Heaney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox