Re: Ada compiler differences

[Stephen Leake <stephen_leake@acm.org>]

Nick Roberts <nick.roberts@acm.org> writes:

> Magnus wrote:
> > Or rather: how can I write code that really is platform (and
> > compiler) independent in Ada?
> 
> Generally, you cannot. 

This is a gross overstatement, and a horrible diservice to Ada.

The real answer is: "Generally, for applications that do not deal
directly with hardware or other target-dependent features, you can".

Part of the point of Ada is to allow users to write portable code!

> However, you generally /can/ write Ada programs that require very
> little changes to be ported. Typically, the best technique is to
> move everything that might need to be changed during a port into
> separate (library) packages, so that the places where changes are
> required are isolated from the rest of the code.

That is good advice in any language.

> There are lots of subtle gotchas, unfortunately, that you may need to
> watch out for. I can list a few.
> 
> Re-entrancy of pre-defined subprograms: on some implementations, if two
> tasks make simultaneous calls to a subprogram in certain pre-defined
> library packages, one or both will not work correctly. 

This is also true independent of language. When writing multi-threaded
code, you need to be aware of thread issues.

> If you are lucky, your program will just crash; if you are unlicky,
> it will be a source of subtle, intermittent, infuriatingly
> uncatchable bugs. Theoretically, this should never happen unless
> both subprogram calls make reference to the same variable (or file).
> In practice, I think you'll find some implementations are less than
> perfect in this area. 

Hmm. If the Language Reference Manual does not _explicitly_ state that
a particular function is safe for calling from multiple tasks, then
you must assume it is not, and provide your own layer of task
protection for it. I suspect Nick has been violating this rule.

> If you are not careful, you can run into re-entrancy problems with
> your own subprograms, too. Since different implementations can
> multitask in very different ways, its often the case that a
> potential re-entrancy problem doesn't manifest itself until a
> program is ported.

That is bad design, in any language. One of the reasons Ada defines
tasking in the language is to allow people to write portable
muli-tasking code.

So the correct statement here is "If you follow good multi-tasking
design principles, Ada lets you easily write portable multi-tasking
code".

> Aliasing: implementations are sometimes allowed to choose whether to
> pass a parameter by value or by reference (indirectly). If it so
> happens that a call to a subprogram effectively passes the same
> variable as two different (formal) parameters, the subprogram has
> two different 'paths' to the variable, without knowing it. The order
> in which updates to the variable occur could change from one
> implementation to another, in this situation. This can be a source
> of some really mysterious bugs, when porting.

True. Also easy to avoid, once you are aware of it. Hmm. There aught
to be an ASIS based tool to check for this.

> Order dependency: implementations are generally allowed to choose in what
> order they evaluate the expressions passed as (actual) parameters to a
> subprogram call. If more than one of these expressions has a side-effect,
> and the side-effects could interact in some way, it possible that the
> order the implementation chooses could affect the behaviour of a program.
> This can be a source of subtle and nasty bugs when porting.

While technically true, I don't recall anyone posting such a bug here.
And I have never encountered such a bug. Typical code just doesn't
have this problem.

> The values of everything declared in the predefined package 'System' are
> all implementation defined, as well as in its children, and the
> subprograms will all work differently. There may be extra imp-def
> declarations, and some declarations may be omitted or different to what
> the standard states. So use of these packages needs care, from a
> portability perspective. It's best to avoid using anything here if you
> can.

True.

Another area of non-portability is GUI interfaces. Since the Ada
standard does not define a GUI library, code you write using a GUI
library is only as portable as that library.


-- Stephe
___________________________________________________________
This mail sent using ToadMail -- Web based e-mail @ ToadNet