* Adding Things to Package System @ 1999-02-18 0:00 Charles H. Sampson 1999-02-18 0:00 ` dewar 1999-02-23 0:00 ` Tucker Taft 0 siblings, 2 replies; 10+ messages in thread From: Charles H. Sampson @ 1999-02-18 0:00 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-18 0:00 Adding Things to Package System Charles H. Sampson @ 1999-02-18 0:00 ` dewar 1999-02-20 0:00 ` Charles H. Sampson 1999-02-23 0:00 ` Tucker Taft 1 sibling, 1 reply; 10+ messages in thread From: dewar @ 1999-02-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-18 0:00 ` dewar @ 1999-02-20 0:00 ` Charles H. Sampson 1999-02-20 0:00 ` Matthew Heaney 1999-02-21 0:00 ` dewar 0 siblings, 2 replies; 10+ messages in thread From: Charles H. Sampson @ 1999-02-20 0:00 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-20 0:00 ` Charles H. Sampson @ 1999-02-20 0:00 ` Matthew Heaney 1999-02-21 0:00 ` dewar 1 sibling, 0 replies; 10+ messages in thread From: Matthew Heaney @ 1999-02-20 0:00 UTC (permalink / raw) 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#); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-20 0:00 ` Charles H. Sampson 1999-02-20 0:00 ` Matthew Heaney @ 1999-02-21 0:00 ` dewar 1 sibling, 0 replies; 10+ messages in thread From: dewar @ 1999-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-18 0:00 Adding Things to Package System Charles H. Sampson 1999-02-18 0:00 ` dewar @ 1999-02-23 0:00 ` Tucker Taft 1999-02-26 0:00 ` Charles H. Sampson 1 sibling, 1 reply; 10+ messages in thread From: Tucker Taft @ 1999-02-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-23 0:00 ` Tucker Taft @ 1999-02-26 0:00 ` Charles H. Sampson 1999-02-27 0:00 ` Tucker Taft 1999-02-28 0:00 ` robert_dewar 0 siblings, 2 replies; 10+ messages in thread From: Charles H. Sampson @ 1999-02-26 0:00 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-26 0:00 ` Charles H. Sampson @ 1999-02-27 0:00 ` Tucker Taft 1999-02-28 0:00 ` dewar 1999-02-28 0:00 ` robert_dewar 1 sibling, 1 reply; 10+ messages in thread From: Tucker Taft @ 1999-02-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-27 0:00 ` Tucker Taft @ 1999-02-28 0:00 ` dewar 0 siblings, 0 replies; 10+ messages in thread From: dewar @ 1999-02-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Things to Package System 1999-02-26 0:00 ` Charles H. Sampson 1999-02-27 0:00 ` Tucker Taft @ 1999-02-28 0:00 ` robert_dewar 1 sibling, 0 replies; 10+ messages in thread From: robert_dewar @ 1999-02-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1999-02-28 0:00 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-02-18 0:00 Adding Things to Package System Charles H. Sampson 1999-02-18 0:00 ` dewar 1999-02-20 0:00 ` Charles H. Sampson 1999-02-20 0:00 ` Matthew Heaney 1999-02-21 0:00 ` dewar 1999-02-23 0:00 ` Tucker Taft 1999-02-26 0:00 ` Charles H. Sampson 1999-02-27 0:00 ` Tucker Taft 1999-02-28 0:00 ` dewar 1999-02-28 0:00 ` robert_dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox