Adding Things to Package System

Adding Things to Package System

[Charles H. Sampson]

     I've just come across what looks like an interesting bug in both 
the Green Hills and ObjectAda compilers.  While the bug itself is inter-
esting, the questions it raises are more so.

     The problem is illustrated by the following package:

     with System.Storage_elements;
     Package Address_arithmetic_bug is

     -- The following use type declaration makes
     
     --   function "+"(Left : Address; Right : Storage_offset)
     --     return Address;
     
     -- directly visible (among other things).
     
        use type System.Storage_elements.Storage_offset;
     
     -- The following use type declaration seems to cause the problem:
     
        use type System.Address;
     
        First_address : constant System.Address := 
         System.Storage_elements.To_address (16#10_000#);
         
        Second_address : constant System.Address := First_address + 1;
     
     end Address_arithmetic_bug;

     The compilers complain that the addition of an object of type Ad-
dress and an integer literal is ambiguous.  They do not give any details 
about which "+" operations are directly visible.  The code does compile 
o. k. under GNAT.

     I haven't received a reply to my bug report from Green Hills, but I 
suspect that a "+" operation has been added to package System that is 
made directly visible by the second use type clause.  If so, then we 
have an apparent conflict in the LRM.  13.7(36) clearly allows such ad-
ditions (although it discourages them), yet this is legal code that the 
compiler can't handle, in violation of 1.1.3(2).

     Am I correct in assuming that 1.1.3(2) rules?  If so, then how does 
that paragraph reconcile with 1.1.3(6), which appears to condone the ad-
dition?

     Offhand, it looks like any addition to System could give rise to 
similar problems.  For example, suppose an identifier is added to System 
and this identifier is also used in package Pkg.  Then, in the presence 
of use System and use Pkg clauses, that identifier would not be directly 
visible, although it would be for a compiler that uses the "minimal" 
package System.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Adding Things to Package System

[dewar]

In article <1999Feb18.192159.18832@nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
> I've just come across what looks like an interesting
> bug in both ... compilers.

<<description of effect of adding stuff to System making
  programs illegal>>

ANY addition to System will make some legal programs
illegal, and it is indeed a very bad idea to add stuff
to System.

In GNAT, we use EXACTLY the RM definition of System,
precisely to avoid these nasty kinds of effects.

Now of course we also need compatibility with other Ada
compilers who have (perhaps injudiciously in the past)
added junk to System, notably DEC Ada 83, which adds piles
of stuff.

Our solution to this is the pragma

  pragma Extend_System (package_name);

which takes the given package and merges its declarations
into an extended version of package System. This of course
leads to the kind of problems Charles mentions, but you
only get them if you ask for them.

It is particularly a VERY bad idea to add address
arithmetic operations to System. It causes the serious
kind of problems that Charle's mentions, and I am a little
surprised that other Ada 95 compilers would make this
mistake. Perhaps their users never use USE statements or
even USE TYPE statements :-)

The trouble is that if you add address arithmetic to
System, and do a USE SYSTEM, which even many USE-allergic
folks will tolerate, then the "proper" way of doing address
arithmetic in Ada 95 will not work. This seems a severe
inconvenience to me. Are you sure you are making a correct
analysis of other compilers here?

Robert Dewar
Ada Core Technologies

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

Re: Adding Things to Package System

[Charles H. Sampson]

In article <7ai6f5$7hk$1@nnrp1.dejanews.com>,  <dewar@gnat.com> wrote:
>In article <1999Feb18.192159.18832@nosc.mil>,
>  claveman@cod.nosc.mil (me) wrote:
>> I've just come across what looks like an interesting
>> bug in both ... compilers.
>
><<description of effect of adding stuff to System making
>  programs illegal>>
>
>ANY addition to System will make some legal programs
>illegal, and it is indeed a very bad idea to add stuff
>to System.
>
>In GNAT, we use EXACTLY the RM definition of System,
>precisely to avoid these nasty kinds of effects.
>
>Now of course we also need compatibility with other Ada
>compilers who have (perhaps injudiciously in the past)
>added junk to System, notably DEC Ada 83, which adds piles
>of stuff.
>
>Our solution to this is the pragma
>
>  pragma Extend_System (package_name);
>
>which takes the given package and merges its declarations
>into an extended version of package System. This of course
>leads to the kind of problems Charles mentions, but you
>only get them if you ask for them.

     What a nice implementation!  Simple and clean.  But why did you do 
it this way rather than following the advice (contained within the im-
plementation permission section of 13.7) of a child package?  Are you
actually trying to capture Dec Ada code?

> ...

>The trouble is that if you add address arithmetic to
>System, and do a USE SYSTEM, which even many USE-allergic
>folks will tolerate, then the "proper" way of doing address
>arithmetic in Ada 95 will not work. This seems a severe
>inconvenience to me. Are you sure you are making a correct
>analysis of other compilers here?

     Package System in both the Green Hills and ObjectAda implementa-
tions contain a declaration similar to

      function "+" (Left : Address, Right : Integer) return Address;

as well as the commutative variation.  Green Hills, which is my vendor, 
didn't tell me why they chose to ignore the advice.  I have no idea why
ObjectAda did either; they're a colleague's vendor and he doesn't have
time to ask them right now.  (He's in typical alligator-fighting mode.)

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Adding Things to Package System

[Matthew Heaney]

claveman@cod.nosc.mil (Charles H. Sampson) writes:

>      Package System in both the Green Hills and ObjectAda implementa-
> tions contain a declaration similar to
> 
>       function "+" (Left : Address, Right : Integer) return Address;
> 
> as well as the commutative variation.  Green Hills, which is my vendor, 
> didn't tell me why they chose to ignore the advice.  I have no idea why
> ObjectAda did either; they're a colleague's vendor and he doesn't have
> time to ask them right now.  (He's in typical alligator-fighting mode.)


We're using the VADS compiler, and they did something _really_ dumb:

   function "+" (L : Address; Right : Integer) return Address;

   function "+" (L : Address; Right : Long_Integer) return Address;

So the call

   Addr := Base_Addr + 16#5000#;

is ambiguous!  So you have to do this

   Addr := Base_Addr + Integer'(16#5000#);   

Re: Adding Things to Package System

[dewar]

In article <1999Feb20.003952.9906@nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:

<<description of GNAT pragma Extend_System snipped>>

> What a nice implementation!  Simple and clean.  But
> why did you do  it this way rather than following the
> advice (contained within the implementation permission
> section of 13.7) of a child package?  Are you actually
> trying to capture Dec Ada code?

But our implementation *is* a child package, and of course
it is much better to do

   with System.Aux_DEC;

and in this case you do not need to use the Extend_System
pragma. But, as you hint in your last sentence, that does
not provide 100% compatibility with DEC Ada code, and,
especially on DEC Alpha VMS, GNAT aims at a VERY close
level of compatibility (for example, we expect to be able
to execute almost all of the tests in the GNAT test suite
unchanged, and similarly, to execute customer's code with
no changes).

This requires a much deeper level of integration, the extra
declarations must be an integral part of standard, and that
is what is achieved by the Extend_System pragma.

This way, you have the best of both worlds, you can use
either the RM advised (and obviously preferable) approach
of a child package if you are writing new code, or if you
are willing to do surgery to your code, and use the
Extend_System pragma if you want absolute compatibility.

Note that we only provide Aux_DEC at the moment as part of
the actual GNAT distribution, but a user can provide any
set of auxiliary declarations. So if you have code from one
of these other Ada 95 compilers which (unwisely in both my
view, and as Charles points out, the RM's point of view),
adds junk to System, you can provide an exactly compatible
GNAT environment by adding the same junk to System using
the Extend_System pragma :-)

Robert Dewar
Ada Core Technologies


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

Re: Adding Things to Package System

[Tucker Taft]

Charles H. Sampson wrote:
> 
>      I've just come across what looks like an interesting bug in both
> the Green Hills and ObjectAda compilers.

This is not a compiler bug.  It is presumably an attempt
to provide backward compatibility with Ada 83 compilers.
The GNAT approach to handling this problem is nice,
but unfortunately it is also non-standard.

From the user perspective, the portable solution to your problem
is to avoid having a "use" clause for package System,
or to qualify any literal with Storage_Offset'(...).

In general, because implementations are allowed to
add arbitrary stuff to package System, you will always
be opening your programs up to non-portability by putting
in a "use System;".

>      I haven't received a reply to my bug report from Green Hills, 

It isn't a bug, just an implementation-dependent aspect
of Ada.

> ... yet this is legal code that the
> compiler can't handle, in violation of 1.1.3(2).

It is not portably "legal" code, unfortunately.  It is
code that is legal if there are no additions to package
System, but as you point out, additions to package System
are permitted.

>      Am I correct in assuming that 1.1.3(2) rules?

No.  Your code is not "universally" legal.  To
minimize non-portabilities, remove any "use" for package System.
Use a rename if you find "System." too painful an addition
at every reference to some declaration in package System.

>                                 Charlie
> --
> ******
> 
>      For an email response, my user name is "sampson" and my host
> is "spawar.navy.mil".

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Adding Things to Package System

[Charles H. Sampson]

In article <36D31FC0.A39BEBAA@averstar.com>,
Tucker Taft  <stt@averstar.com> wrote:
>Charles H. Sampson wrote:
>> 
>> ... yet this is legal code that the
>> compiler can't handle, in violation of 1.1.3(2).
>
>It is not portably "legal" code, unfortunately.  It is
>code that is legal if there are no additions to package
>System, but as you point out, additions to package System
>are permitted.
>
>>      Am I correct in assuming that 1.1.3(2) rules?
>
>No.  Your code is not "universally" legal.  To
>minimize non-portabilities, remove any "use" for package System.
>Use a rename if you find "System." too painful an addition
>at every reference to some declaration in package System.
>
     While the discussion to date has been interesting, I was just 
about to post a followup noting that no one had responded to my pointing 
out that three paragraphs of the LRM are in conflict.  Then Tucker Taft 
took care of that, as he often does.

     I'm not really happy with Tucker's response, but I'm not too sur-
prised either.  I am a little surprised about a couple of terms that I'm 
not familiar with: "portably 'legal' code" and "'universally' legal".  
Other than that, I suppose that the demon Practicality is going to com-
mand that additions to System be allowed in the near term.  Perhaps in 
Ada 200X, ...

     Still, even though it's not surprising, saying that 1.1.3(2) is 
not a hard rule is disturbing.  Robert Dewar and I agree that additions 
to System are a poor idea.  Matthew Heaney has given an example of some 
spectacularly injudicious additions.  In spite of that, the rule that a 
conforming implementation must handle all legal Ada programs is "bent" 
to allow these additions.  (I haven't been able to find the definition 
of a legal Ada program, using the index of the LRM as my main tool.  My 
guess would be that it is a program written in the language as described 
in the LRM.  In that case, my program was legal.)

     I almost always write highly portable code.  I do it by being very 
careful of how I use those features that have implementation dependen-
cies and by not using implementation additions unless absolutely neces-
sary.  However, in the present example, I was tripped up by an addition 
that I wasn't using.  I guess I felt a little let down by the LRM.

     Yes, there are a number of ways of getting around the problem of 
additions to System, but I don't see why I should have to.  I would like 
to see some authority (is an ARG 95 in business?) come out very strongly 
in favor of the second sentence of 13.7(36): Any additions to System 
should be done in a child package rather than in System itself.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Adding Things to Package System

[Tucker Taft]

Charles H. Sampson (claveman@cod.nosc.mil) wrote:

: ...
:      I'm not really happy with Tucker's response, but I'm not too sur-
: prised either.  I am a little surprised about a couple of terms that I'm 
: not familiar with: "portably 'legal' code" and "'universally' legal".  
: Other than that, I suppose that the demon Practicality is going to com-
: mand that additions to System be allowed in the near term.  Perhaps in 
: Ada 200X, ...

I didn't mean anything mysterious about "universally" or "portably" legal.

Fundamentally, your program as written isn't portable.
It is legal on some compilers, and illegal on others.

Ada 83 allowed additions to System, and to Standard
for that matter.  To write a portable Ada 83 program,
you had to take this into account.  Unfortunately, we
could not easily eliminate this source of non-portabilities
by Ada 95 fiat, given the > 100M LOC of Ada 83 code.

:      Still, even though it's not surprising, saying that 1.1.3(2) is 
: not a hard rule is disturbing.  

It is a hard rule.  But it is relative to a particular environment.
An Ada program is not legal independent of the environment in
which it is compiled.  It must accommodate the particular package Standard 
and the particular library units in the environment.  In some environments,
package Standard and/or package System might have additional declarations.

: ... In spite of that, the rule that a 
: conforming implementation must handle all legal Ada programs is "bent" 
: to allow these additions.    

Again, there is no bending.  It is a simple case of allowed
implementation- dependence in the specification for a language-defined
package.

: ... (I haven't been able to find the definition 
: of a legal Ada program, using the index of the LRM as my main tool.  My 
: guess would be that it is a program written in the language as described 
: in the LRM.  In that case, my program was legal.)

A program is legal if it satisfies the syntax, name resolution
rules, and legality rules in the LRM.  Your program violated one
of the name resolution rules because of a permitted variation in
a language-defined package.

:      I almost always write highly portable code.  I do it by being very 
: careful of how I use those features that have implementation dependen-
: cies and by not using implementation additions unless absolutely neces-
: sary.  However, in the present example, I was tripped up by an addition 
: that I wasn't using.  I guess I felt a little let down by the LRM.

Because implementation are permitted to add declarations to packge
System, "use System;" is a "non-portable feature".  You may need to
add that to your list of things to avoid.

:      Yes, there are a number of ways of getting around the problem of 
: additions to System, but I don't see why I should have to.  

You only "have to" do it if you want to create maximally portable
programs.

: ... I would like 
: to see some authority (is an ARG 95 in business?) come out very strongly 
: in favor of the second sentence of 13.7(36): Any additions to System 
: should be done in a child package rather than in System itself.

The key word is "should" here.  It is implementation advice, not
a hard requirement, and because of the large amount of existing Ada 83 
code, some vendors have felt obliged to maximize upward compatibility.

Perhaps the real mistake was not to be more explicit in some RM "NOTE"
that any "use" clause for package System is inherently non-portable, because
additions to package System are permitted.

For what it is worth, other non-portabilities to be aware of are
ueses of names like "Byte_Integer", "Short_Integer", "Long_Long_Integer"
in your own packages which you then "use," because of potential
conflicts with additions to package Standard.

As you point out, portability is not an absolute in Ada 95, and
requires some user effort to achieve.  Avoiding "use System;" is
part of the effort required to maximize portability.

: 				Charlie

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Adding Things to Package System

[dewar]

In article <F7tILv.GGv.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Ada 83 allowed additions to System, and to Standard
> for that matter.  To write a portable Ada 83 program,
> you had to take this into account.  Unfortunately, we
> could not easily eliminate this source of
> non-portabilities by Ada 95 fiat, given the > 100M LOC of
> Ada 83 code.

I disagree. I think we made a mistake here. We should NOT
have permitted such additions to System at all. This would
have the effect of requiring compilers to have a mode in
which no additions to System were allowed. They could also
have mechanisms for allowing such additions where they were
needed for compatibility.

Our experience with GNAT is that this is easy to do. The
normal mode in GNAT has ZERO additions to System, but we
can still easily provide complete compatibility with old
Ada 83 code that has such additions (e.g. we have a mode
in which we completely emulate the DEC Ada 83 System, which
has many additions).

Robert Dewar
Ada Core Technologies

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

Re: Adding Things to Package System

[robert_dewar]

In article <1999Feb26.202551.9334@nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
> I would like
> to see some authority (is an ARG 95 in business?) come
> out very strongly
> in favor of the second sentence of 13.7(36): Any
> additions to System
> should be done in a child package rather than in System
> itself.

Yes the ARG is still in business, but what point is there
in the action you recommend. The RM is already "strongly
in favor of the second sentence of 13.7(36)". A ruling
from the ARG that says nothing more than "we are in favor
of this sentence, and we think the RM is right, and people
should follow this advice" would seem completely useless to
me.

Note that there is a good reason for this rule: It was to
allow existing Ada 83 compilers to be converted to Ada 95
without introducing incompatibilities from the removal of
stuff in System.

It is certainly valuable for a compiler to at least have
a mode in which it does not add junk to System. If this
is an important criterion for you in compiler acquisition,
then fair enough, make it an up-front requirement!

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