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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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!news1.google.com!news.glorb.com!news.agarik.com!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Ada compiler differences Date: Tue, 19 Oct 2004 21:32:55 -0400 Organization: Cuivre, Argent, Or Message-ID: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: melchior.cuivre.fr.eu.org 1098236018 40302 212.85.156.195 (20 Oct 2004 01:33:38 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 20 Oct 2004 01:33:38 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: X-Authentication-Warning: fajita.toad.net: apache set sender to stephen_leake@acm.org using -f User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:5482 Date: 2004-10-19T21:32:55-04:00 Nick Roberts 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