comp.lang.ada
 help / color / mirror / Atom feed
From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: Binary files vs Portablity vs Ada
Date: 1999/11/09
Date: 1999-11-09T00:00:00+00:00	[thread overview]
Message-ID: <80866f$4oq$1@nnrp1.deja.com> (raw)
In-Reply-To: 8074m8$bk8$1@nnrp1.deja.com

In article <8074m8$bk8$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> Even in the two compiler case, you're nessecarily not off the
hook. The
> "required" documentation is often inadaquate, out of date, or
just plain
> wrong. I have found two different vendors for which that
applies (not
> ACT, but then I haven't read through ACT's annex M). When I
mentioned
> this here, I was told there's no "validation test suite" for
> documentation. So apparently a crappy annex M implementation
(or perhaps
> even *no* annex M at all) will not in any way hamper a
vendor's ability
> to get or keep an Ada validation.

No, but it should hinder you choosing a vendor who does not
provide this required essential documentation.

The point here is that you have to be reasonable about
portability. The implementation advice is really a set of
things which you can reasonably assume about code in writing
portable code.

Writing portable code is not about fanatically sticking to the
set of things that is absolutely guaranteed by the RM. Indeed
no programs can be written under that requirement, since any
program is allowed to raise Storage_Error at any point.

Writing portable code is about writing code that in practice
ports with minimum effort. You need to have a good sense of
what is and what is not reasonable to assume in this task, and
the implementation advice is precisely intended to help you.

You should indeed insist contractually on your vendor telling
you whether implementation advice is followed. If you are taking
the position that a compiler being validated is sufficient
guarantee that it is acceptable for your use, then that's
passing the buck. Ada users have to be prepared to do some
reasonable homework in choosing an Ada compiler. Checking out
the documentation is part of that homework.

I definitely would insist on a complete annex M, it is an
important requirement. If your vendor says they conform to the
RM, then they must provide this documentation (validation does
not prove conformance, and in particular there is no practical
way to formally validate documentation -- one could have a
requirement that annex M be present, but that's too weak to
be useful).

My advice: when choosing an Ada compiler, put the provision of
a complete and useful Annex M on your check list!

And, going back to the original issue, this particular IA is
something you can reasonably count on. Sure it is technically
possible for a compiler to refuse to follow this IA, but
unlikely, probably much less likely than having a bug in the
implementation, and no amount of reading the RM protects you
against that.


Sent via Deja.com http://www.deja.com/
Before you buy.




  parent reply	other threads:[~1999-11-09  0:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-11-04  0:00 Binary files vs Portablity vs Ada John Halleck
1999-11-05  0:00 ` Larry Kilgallen
1999-11-05  0:00   ` John Halleck
1999-11-05  0:00 ` Robert Dewar
1999-11-05  0:00   ` Ted Dennison
1999-11-06  0:00     ` Robert Dewar
1999-11-08  0:00       ` Ted Dennison
1999-11-08  0:00         ` Tucker Taft
1999-11-09  0:00           ` Robert Dewar
1999-11-09  0:00         ` Robert A Duff
1999-11-09  0:00           ` Advice, or *Advice*? (was: Binary files vs Portablity vs Ada) Ted Dennison
1999-11-10  0:00             ` Robert A Duff
1999-11-09  0:00         ` Robert Dewar [this message]
1999-11-05  0:00 ` Binary files vs Portablity vs Ada Matthew Heaney
1999-11-08  0:00 ` Nick Roberts
1999-11-09  0:00   ` Robert Dewar
1999-11-09  0:00   ` Ted Dennison
replies disabled

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