From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4ef4bf3098ab117 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: Ada compiler differences Date: Mon, 18 Oct 2004 21:36:19 +0100 Message-ID: <2tinq4F20cumjU1@uni-berlin.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de kP/TDZPg7quz9rlyC8wcAwxojYXQVSIkHu+fP7rDj0WlVclz0= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:5416 Date: 2004-10-18T21:36:19+01:00 List-Id: 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