Ada compiler differences

Ada compiler differences

[Magnus]

Hello,

Could someone please point me to a list of things that may be
implementation dependent in different ADA compilers and/or on
different platforms?

I know that things like 'access and structures without repspec may
differ. But what else?

Or rather: how can I write code that really is platform (and compiler)
independent in Ada?

Cheers,
Magnus

Re: Ada compiler differences

[Jacob Sparre Andersen]

Magnus wrote:

> Could someone please point me to a list of things that may be
> implementation dependent in different Ada compilers and/or on
> different platforms?

There is a list in one of the last sections in the language reference
manual.

> Or rather: how can I write code that really is platform (and
> compiler) independent in Ada?

One advice:

 * Don't depend on predefined types (Integer, Float, Natural, etc.)
   where it makes more sense to declare a specific type for your
   specific use.

(you'll probably get more)

Greetings,

Jacob
-- 
�When Roman engineers built a bridge, they had to stand under it while
 the first legion marched across. If programmers today worked under
 similar ground rules, they might well find themselves getting much more
 interested in Ada!�                                     -- Robert Dewar

Re: Ada compiler differences

[Luke A. Guest]

On Mon, 18 Oct 2004 16:01:50 +0200, Jacob Sparre Andersen wrote:

>> Or rather: how can I write code that really is platform (and
>> compiler) independent in Ada?
> 
> One advice:
> 
>  * Don't depend on predefined types (Integer, Float, Natural, etc.)
>    where it makes more sense to declare a specific type for your
>    specific use.

Yeah, you'll need to define your own types, but surely these are going to
be "derived" from the default types, i.e.

  type Chutney is new Integer range 1 .. 5;

Are you saying not to even do this?

Thanks,
Luke.

Re: Ada compiler differences

[Nick Roberts]

Luke A. Guest wrote:

> Yeah, you'll need to define your own types, but surely these are going
> to be "derived" from the default types, i.e.
> 
>   type Chutney is new Integer range 1 .. 5;
> 
> Are you saying not to even do this?

Yes. Normally it is better to simply put:

   type Chutney is range 1..5;

and allow the implementation to select the best base type.

-- 
Nick Roberts

Re: Ada compiler differences

[Nick Roberts]

Magnus wrote:

> Could someone please point me to a list of things that may be
> implementation dependent in different ADA compilers and/or on
> different platforms?

One could write a book about this subject. It is too complex to state
completely in a few paragraphs.

The first question you should ask, for a particular program you are
developing, is "Does this need to be portable?" In most cases, the
answer will be "No", and so your question does not arise.

Admittedly, it can occasionally happen that a problem which would
normally be categorised as a porting problem can occur when upgrading
from one version of a compiler to the next.

For cases where it does arise:

> I know that things like 'access and structures without repspec may
> differ. But what else?

The underlying representation (and implementational details) of these
things will differ, but their semantics (as defined by the standard)
should not.

The general principle is that if you write your program so that its
correctness depends only upon the semantics required by the Ada
standard, you should be able to port the program without having to
change it. The standard carefully defines which aspects are
implementation defined.

If timing considerations are really important, you may well have
considerable porting problems anyway.

> Or rather: how can I write code that really is platform (and
> compiler) independent in Ada?

Generally, you cannot. 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.

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. 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. 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.

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.

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.

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.

-- 
HTH
Nick Roberts

Re: Ada compiler differences

[Martin Dowie]

Luke A. Guest wrote:
>>  * Don't depend on predefined types (Integer, Float, Natural, etc.)
>>    where it makes more sense to declare a specific type for your
>>    specific use.
>
> Yeah, you'll need to define your own types, but surely these are
> going to be "derived" from the default types, i.e.
>
>  type Chutney is new Integer range 1 .. 5;
>
> Are you saying not to even do this?

Absolutelty! :-)

Leave as many aspects of the underlying representation to the compiler. It 
know what the target is, so in this case it may choose a 8-bit 
representation as opposed to say a 32-bit one. Perhaps the target has faster 
instructions for 8-bit data items.

Cheers

-- Martin




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004 

Re: Ada compiler differences

[Mark H Johnson]

Magnus wrote:
> Hello,
> 
> Could someone please point me to a list of things that may be
> implementation dependent in different ADA compilers and/or on
> different platforms?
> 
I would start with chapter 13 of the Ada Reference Manual. Simple things 
like Integer'Size (e.g., 32) might not equal Natural'Size (e.g., 31) can 
trip you up in a variety of different ways. I also had problems with 
some code assuming 'Size of the object was the same as 'Size of the 
corresponding type.

I would also suggest a review of the Annotated ARM as well. The 
annotations are quite enlightening when trying to determine the possible 
implementation details of the language.

> I know that things like 'access and structures without repspec may
> differ. But what else?
> 
See above.

> Or rather: how can I write code that really is platform (and compiler)
> independent in Ada?
> 
To do that fully would require an extensive list of issues and is often 
constrained by the types of platforms you expect to run on. For a simple 
example, network order (for TCP/IP) is "big endian". If you are on a 
little endian machine, several values need to go through htonl, htons, 
and similar functions to be converted. If you "know" you will always on 
a big endian machine (same as network order), you might get away without 
them, but that isn't portable.

That particular issue has nothing to do with Ada; you have the same 
problem with C or other languages.

   --Mark

Re: Ada compiler differences

[Jeffrey Carter]

Luke A. Guest wrote:

> Yeah, you'll need to define your own types, but surely these are going to
> be "derived" from the default types, i.e.
> 
>   type Chutney is new Integer range 1 .. 5;
> 
> Are you saying not to even do this?

I rarely do this. What is the point of specifying the representation 
(except at the edges of the application)? Why use 32 (or 64) bits for 5 
values? Let the compiler choose the best representation for the target.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Ada compiler differences

[Larry Kilgallen]

In article <WSWcd.8$V_2.4@dfw-service2.ext.ray.com>, Mark H Johnson <mark_h_johnson@raytheon.com> writes:
> Magnus wrote:

>> Or rather: how can I write code that really is platform (and compiler)
>> independent in Ada?
>> 
> To do that fully would require an extensive list of issues and is often 
> constrained by the types of platforms you expect to run on. For a simple 
> example, network order (for TCP/IP) is "big endian". If you are on a 
> little endian machine, several values need to go through htonl, htons, 
> and similar functions to be converted. If you "know" you will always on 
> a big endian machine (same as network order), you might get away without 
> them, but that isn't portable.
> 
> That particular issue has nothing to do with Ada; you have the same 
> problem with C or other languages.

In particular, it has to do with the fact that TCP/IP was devised on
an ad-hoc basis rather than using an underlying marshalling technique
such as promoted by ASN.1.

Re: Ada compiler differences

[Mark H Johnson]

Larry Kilgallen wrote:

> In article <WSWcd.8$V_2.4@dfw-service2.ext.ray.com>, Mark H Johnson <mark_h_johnson@raytheon.com> writes:
> 
> [snip big endian TCP/IP example]

>>That particular issue has nothing to do with Ada; you have the same 
>>problem with C or other languages.
> 
> 
> In particular, it has to do with the fact that TCP/IP was devised on
> an ad-hoc basis rather than using an underlying marshalling technique
> such as promoted by ASN.1.

I am not quite sure how this comment is relevant to the OP's question on 
writing portable software. Are you suggesting to the OP that they use 
something like an ASN.1 library instead of Posix functions? If so, how 
is that "better" for the problem I described?

   --Mark

Re: Ada compiler differences

[Luke A. Guest]

On Mon, 18 Oct 2004 20:55:15 +0100, Nick Roberts wrote:

> Luke A. Guest wrote:
> 
>> Yeah, you'll need to define your own types, but surely these are going
>> to be "derived" from the default types, i.e.
>> 
>>   type Chutney is new Integer range 1 .. 5;
>> 
>> Are you saying not to even do this?
> 
> Yes. Normally it is better to simply put:
> 
>    type Chutney is range 1..5;
> 
> and allow the implementation to select the best base type.

Even if you use a use clause to specify how many bits you want it to take
up (i.e. even in a record)?

Thanks,
Luke.

Re: Ada compiler differences

[Jeffrey Carter]

Luke A. Guest wrote:

> Even if you use a use clause to specify how many bits you want it to take
> up (i.e. even in a record)?

The only reason to do that is because you need to map to something like 
hardware where this is required, so it's a fairly rare case (what I 
called the edges of software). Even then, there's no advantage to using 
a derived type. Indeed, using a derived type is giving contradictory 
information to the compiler: "use the same representation as Integer" 
and "use only N bits".

-- 
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus
53

Re: Ada compiler differences

[Stephen Leake]

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

Re: Ada compiler differences

[Simon Wright]

Stephen Leake <stephen_leake@acm.org> writes:

> 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.

What, even Generic_Elementary_Functions.Arctan?!

On the other hand, anyone who called Float_Random from two tasks *with
the same generator* would be entitled to expect truly random results.
I think you have to be prepared to use your wits sometimes ..

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada compiler differences

[Rod Chapman]

koma@lysator.liu.se (Magnus) wrote in message news:<dac02c02.0410180447.1a4ed08b@posting.google.com>...
> Or rather: how can I write code that really is platform (and compiler)
> independent in Ada?

Write the code in SPARK, which has only 2 known implementation-defined
features - the range of predefined base types (which can be added
by way of annotations), and the finer details of floating point
(signed zeros, rounding mode etc.)

Example: the port of the SPARK Examiner (written in SPARK of course...)
from Solaris to Linux took...about 20 minutes, most of which was
spent installing GNAT.  The Examiner is about 70kloc, so hardly
a trivial program.
 - Rod

Re: Ada compiler differences

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@acm.org> writes:
> 
> > 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.
> 
> What, even Generic_Elementary_Functions.Arctan?!

Well, you have a point. Although, on a system without floating point
hardware, this _could_ use a global cache of previously computed
results, which _could_ be not task safe.

> On the other hand, anyone who called Float_Random from two tasks
> *with the same generator* would be entitled to expect truly random
> results. I think you have to be prepared to use your wits sometimes
> ..

It could also be argued that the LRM _should_ say more about what is
guarranteed to be task safe.

-- 

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

Re: Ada compiler differences

[Warren W. Gay VE3WWG]

Mark H Johnson wrote:
> Larry Kilgallen wrote:
>> In article <WSWcd.8$V_2.4@dfw-service2.ext.ray.com>, Mark H Johnson 
>> <mark_h_johnson@raytheon.com> writes:
>>
>> [snip big endian TCP/IP example]
> 
> 
>>> That particular issue has nothing to do with Ada; you have the same 
>>> problem with C or other languages.
>>
>> In particular, it has to do with the fact that TCP/IP was devised on
>> an ad-hoc basis rather than using an underlying marshalling technique
>> such as promoted by ASN.1.

The marshalling technique required by ASN.1 requires that all hosts
do "marshalling", whereas big endian machines do not require it
at all (assuming size matches). ASN.1 is just a different representation.
So in addition to Mark's point below, I fail to see why this is
important here.

> I am not quite sure how this comment is relevant to the OP's question on 
> writing portable software. Are you suggesting to the OP that they use 
> something like an ASN.1 library instead of Posix functions? If so, how 
> is that "better" for the problem I described?
> 
>   --Mark
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada compiler differences

[Nick Roberts]

Stephen Leake wrote:

> It could also be argued that the LRM _should_ say more about what is
> guarranteed to be task safe.

Annex A, paragraph 3 states:

   The implementation shall ensure that each language defined subprogram
   is reentrant in the sense that calls on the same subprogram perform as
   specified, so long as all parameters that could be passed by reference
   denote overlapping objects.

I believe subsequent discussions (mentioned in the AARM) have confirmed
that the 'objects' effectively include external files (although strictly
this is implementation defined).

The ARM 83 did not define what had to be task-safe, and I suspect this
is the source of the problems with some Ada 95 implementations.

-- 
Nick Roberts

Re: Ada compiler differences

[Simon Wright]

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

> Annex A, paragraph 3 states:
> 
>    The implementation shall ensure that each language defined subprogram
>    is reentrant in the sense that calls on the same subprogram perform as
>    specified, so long as all parameters that could be passed by reference
>    denote overlapping objects.
            ^non-

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada compiler differences

[Larry Kilgallen]

In article <YDwdd.53169$JG5.650210@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> Mark H Johnson wrote:
>> Larry Kilgallen wrote:
>>> In article <WSWcd.8$V_2.4@dfw-service2.ext.ray.com>, Mark H Johnson 
>>> <mark_h_johnson@raytheon.com> writes:
>>>
>>> [snip big endian TCP/IP example]
>> 
>> 
>>>> That particular issue has nothing to do with Ada; you have the same 
>>>> problem with C or other languages.
>>>
>>> In particular, it has to do with the fact that TCP/IP was devised on
>>> an ad-hoc basis rather than using an underlying marshalling technique
>>> such as promoted by ASN.1.
> 
> The marshalling technique required by ASN.1 requires that all hosts
> do "marshalling", whereas big endian machines do not require it
> at all (assuming size matches).

And as someone who frequents little-endian machines, I can choose some
non-IP protocol a more friendly (to me) one that was designed with no
thought to endian portability.

Re: Ada compiler differences

[Larry Kilgallen]

In article <cf2c6063.0410200002.7d8f4228@posting.google.com>, rod.chapman@praxis-cs.co.uk (Rod Chapman) writes:
> koma@lysator.liu.se (Magnus) wrote in message news:<dac02c02.0410180447.1a4ed08b@posting.google.com>...
>> Or rather: how can I write code that really is platform (and compiler)
>> independent in Ada?
> 
> Write the code in SPARK, which has only 2 known implementation-defined
> features -

I suppose an _unknown_ implementation-defined feature is defined by the
term "bug"  :-)

Re: Ada compiler differences

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:
> In article <YDwdd.53169$JG5.650210@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
>>Mark H Johnson wrote:
>>
>>>Larry Kilgallen wrote:
>>>
>>>>In article <WSWcd.8$V_2.4@dfw-service2.ext.ray.com>, Mark H Johnson 
>>>><mark_h_johnson@raytheon.com> writes:
>>>>
>>>>[snip big endian TCP/IP example]
>>>
>>>
>>>>>That particular issue has nothing to do with Ada; you have the same 
>>>>>problem with C or other languages.
>>>>
>>>>In particular, it has to do with the fact that TCP/IP was devised on
>>>>an ad-hoc basis rather than using an underlying marshalling technique
>>>>such as promoted by ASN.1.
>>
>>The marshalling technique required by ASN.1 requires that all hosts
>>do "marshalling", whereas big endian machines do not require it
>>at all (assuming size matches).
> 
> 
> And as someone who frequents little-endian machines, I can choose some
> non-IP protocol a more friendly (to me) one that was designed with no
> thought to endian portability.

But ASN.1 ain't it because you still have to marshall it. ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada compiler differences

[Nick Roberts]

Simon Wright wrote:

>>Annex A, paragraph 3 states:
>>
>>   The implementation shall ensure that each language defined subprogram
>>   is reentrant in the sense that calls on the same subprogram perform as
>>   specified, so long as all parameters that could be passed by reference
>>   denote overlapping objects.
>           ^non-

Oops! Thanks.

-- 
Nick Roberts

Re: Ada compiler differences

[Mark H Johnson]

Larry Kilgallen wrote:
> In article <YDwdd.53169$JG5.650210@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
>>Mark H Johnson wrote:
>>
>>>Larry Kilgallen wrote:
>>>
>>>>In article <WSWcd.8$V_2.4@dfw-service2.ext.ray.com>, Mark H Johnson 
>>>><mark_h_johnson@raytheon.com> writes:
>>>>
>>>>[snip big endian TCP/IP example]
>>>
>>>
>>>>>That particular issue has nothing to do with Ada; you have the same 
>>>>>problem with C or other languages.
>>>>
>>>>In particular, it has to do with the fact that TCP/IP was devised on
>>>>an ad-hoc basis rather than using an underlying marshalling technique
>>>>such as promoted by ASN.1.
>>
>>The marshalling technique required by ASN.1 requires that all hosts
>>do "marshalling", whereas big endian machines do not require it
>>at all (assuming size matches).
> 
> 
> And as someone who frequents little-endian machines, I can choose some
> non-IP protocol a more friendly (to me) one that was designed with no
> thought to endian portability.

I'll repeat my question [which was snipped in this sequence] since it 
apparently has been ignored....

I am not quite sure how this comment is relevant to the OP's question on 
writing portable software. Are you suggesting to the OP that they use 
something like an ASN.1 library instead of Posix functions? If so, how 
is that "better" for the problem I described?

I raised this question because I recognize in many situations, you have 
to meet an established interface specification. You imply above that 
ignoring the interface (or choosing a different one) is somehow OK. 
Please explain your rationale.

   --Mark

Re: Ada compiler differences

[Rod Chapman]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:
> I suppose an _unknown_ implementation-defined feature is defined by the
> term "bug"  :-)

If you can find _any_ implementation-dependent, implementation-defined, or
erroneous behaviour in SPARK (other than the 2 I mentioned above),
then please report it to sparkinfo@praxis-his.com
 - Rod

Re: Ada compiler differences

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vzn2iq6t4.fsf@smaug.pushface.org...
> Stephen Leake <stephen_leake@acm.org> writes:
>
> > 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.
>
> What, even Generic_Elementary_Functions.Arctan?!

This is wrong. As long as the tasks are not passing the same objects, the
language requires that multiple tasks can call predefined routines at the
same time. See A(3). (That's the third paragraph of the introduction to
Annex A.)

Any implementation that fails to do that for any predefined subprogram is
incorrect. Of course, it is not unusual for implementations to be incorrect,
especially in this area; and that seemed to be Nick's original point.

It will be very important that this property is true for the containers, for
instance.

                            Randy.

Re: Ada compiler differences

[Larry Kilgallen]

In article <1wVdd.5$Au6.4@dfw-service2.ext.ray.com>, Mark H Johnson <mark_h_johnson@raytheon.com> writes:
> Larry Kilgallen wrote:
>> In article <YDwdd.53169$JG5.650210@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>> 
>>>Mark H Johnson wrote:
>>>
>>>>Larry Kilgallen wrote:
>>>>
>>>>>In article <WSWcd.8$V_2.4@dfw-service2.ext.ray.com>, Mark H Johnson 
>>>>><mark_h_johnson@raytheon.com> writes:
>>>>>
>>>>>[snip big endian TCP/IP example]
>>>>
>>>>
>>>>>>That particular issue has nothing to do with Ada; you have the same 
>>>>>>problem with C or other languages.
>>>>>
>>>>>In particular, it has to do with the fact that TCP/IP was devised on
>>>>>an ad-hoc basis rather than using an underlying marshalling technique
>>>>>such as promoted by ASN.1.
>>>
>>>The marshalling technique required by ASN.1 requires that all hosts
>>>do "marshalling", whereas big endian machines do not require it
>>>at all (assuming size matches).
>> 
>> 
>> And as someone who frequents little-endian machines, I can choose some
>> non-IP protocol a more friendly (to me) one that was designed with no
>> thought to endian portability.
> 
> I'll repeat my question [which was snipped in this sequence] since it 
> apparently has been ignored....

If there was a question, _I_ ignored it for lack of context.

> I am not quite sure how this comment is relevant to the OP's question on 
> writing portable software. Are you suggesting to the OP that they use 
> something like an ASN.1 library instead of Posix functions? If so, how 
> is that "better" for the problem I described?

I see nothing in the material quoted above about Posix.  I have never
been on a machine which had an implementation of the Ada bindings to
Posix.

I pointed out that TCP/IP was devised without depending on an underlying
mechanism like ASN.1 implementations which solve the marshalling problem.

I don't believe I see anything above from the initial poster.

> I raised this question because I recognize in many situations, you have 
> to meet an established interface specification. You imply above that 
> ignoring the interface (or choosing a different one) is somehow OK. 
> Please explain your rationale.

We were discussing the issue of TCP/IP implementations requiring special
little routines to resolve endian issues.  More user-friendly mechanisms
do not require that.

Re: Ada compiler differences

[Mark H Johnson]

Larry Kilgallen wrote:
> In article <1wVdd.5$Au6.4@dfw-service2.ext.ray.com>, Mark H Johnson <mark_h_johnson@raytheon.com> writes:
> [snip - lots of back & forth]

> I pointed out that TCP/IP was devised without depending on an underlying
> mechanism like ASN.1 implementations which solve the marshalling problem.
> 
Why is that relevant to the OP's question about implementation 
differences between compilers and platforms?

Are you suggesting that the standard for TCP/IP be reimplemented using 
ASN.1 on a variety of platforms?

I still don't see how your statement above (and in previous messages) 
addresses the OP's question.

   --Mark

Re: Ada compiler differences

[Larry Kilgallen]

In article <qdzfd.10$dK2.7@dfw-service2.ext.ray.com>, Mark H Johnson <mark_h_johnson@raytheon.com> writes:
> Larry Kilgallen wrote:
>> In article <1wVdd.5$Au6.4@dfw-service2.ext.ray.com>, Mark H Johnson <mark_h_johnson@raytheon.com> writes:
>> [snip - lots of back & forth]
> 
>> I pointed out that TCP/IP was devised without depending on an underlying
>> mechanism like ASN.1 implementations which solve the marshalling problem.
>> 
> Why is that relevant to the OP's question about implementation 
> differences between compilers and platforms?

I did not claim that it was relevant to anything I did not quote.
I claimed (implicitly) that it was relevant to the particular part
which I quoted.

> Are you suggesting that the standard for TCP/IP be reimplemented using 
> ASN.1 on a variety of platforms?

I am suggesting that TCP/IP was poorly designed in this regard,
but according to technology available today (ASN.1) which may
not have been available when TCP/IP was designed.

Re: Ada compiler differences

[Mark H Johnson]

Larry Kilgallen wrote:

> I am suggesting that TCP/IP was poorly designed in this regard,
> but according to technology available today (ASN.1) which may
> not have been available when TCP/IP was designed.

That sounds pretty off topic to me. Whatever.

   --Mark