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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-02 01:23:03 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Mon, 02 Feb 2004 10:31:09 +0100 Message-ID: References: <1075225041.167448@master.nyc.kbcfp.com> <1075303237.975898@master.nyc.kbcfp.com> <9khh10pti0dn8gcp7f18ghptaifluj0fud@4ax.com> <1075390647.405841@master.nyc.kbcfp.com> <1075405582.982776@master.nyc.kbcfp.com> <1075482385.142744@master.nyc.kbcfp.com> NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1075713782 31076200 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:5175 Date: 2004-02-02T10:31:09+01:00 List-Id: On Fri, 30 Jan 2004 12:06:26 -0500, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: > >>it is perfectly legal to write code which has unspecified results > >>due to order of execution. >> >> Wrong. Here is ARM 4.5: >> allowed result /= unspecified result > >That very same section says that > The two operands of an expression of the form X op Y, > where op is a binary operator, are evaluated in an > arbitrary order, as for any function_call > >arbitrary order = unspecified result > >If I have (pidgin Ada again!) > x : 0..1 := 0; > function f : integer is begin x := 1 - x; return x; end f; > r : integer := f - f; >Then Ada legally permits r to be 1 or -1. That's what I call >unspecified, i.e., no single result is required. Does the specification of f require single result? It does not, because f could as well call to Random or ask operator for a value. Moreover, there could be a concurrent task modifying x! So it is not Ada, but you who didn't specify it. Should you have written down the full contract of f, a user of f would know whether it is legal to use f as above, or concurrently from different tasks etc. The real [Ada] problem is not order, but that a malignantly impure f can be used as if it were pure. >In a particular >fixed environment, it is likely that the above code will always >return the same value. If this is done in production code rather >than in a contrived example, and the order dependency isn't so >apparent, it will seem that everything is fine. Then a change in >environment can make the opposite result appear, and things may >be broken. Which means that the code is wrong. >Everyone here is saying "so don't do that", which is what we >C/C++ programmers always say, and which you Ada guys sneer at. OK, according to your theory C++ is right requiring to specify parameter passing mode: by-copy vs. by-reference. But it is just one of many evil features of C++! Once per month reviewing code I detect programmers passing constant containers by copy! They do it over and over again. Imagine a test which would catch that? With some exemptions Ada leaves that to the compiler. And yes, it is well possible to write a program which will work if the compiler chooses one mode and crash otherwise. >> Do you really believe that tests will detect an "incorrect" order > > when specified by RM more probably than when selected by the compiler? > >I believe that once code is written, tested, and found to work, then >having the evaluation order chosen by the language means that it will >continue to work even when the environment changes. If the order is >selected by the compiler, then you have no such assurance. Surely >this is obvious? It is not. Because "found to work" /= "found correct". There is a hope that a code dependent on execution order will continue to work so far the order is not changed. But isn't it better to know that the code remains valid for any order? -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de