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,2cb1f0b6d642e1dc X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Pascal Calling Convention Date: Fri, 25 Mar 2011 12:04:33 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <9b04626e-567d-408c-aab3-39b964b3ffd6@l2g2000prg.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1301069073 5235 192.74.137.71 (25 Mar 2011 16:04:33 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 25 Mar 2011 16:04:33 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:K9Q/gFZC3zuoRmvO9SBajFRY7tY= Xref: g2news1.google.com comp.lang.ada:18448 Date: 2011-03-25T12:04:33-04:00 List-Id: Keith Thompson writes: > Dennis Lee Bieber writes: >> i = 0; >> someC(i++, i++, i++); > On my system, it produced (2, 1, 0), but this doesn't mean anything. > In C, the order of evaluation of function arguments is explicitly > unspecified. Furthermore, in this particular case, the multiple > modifications to the same object without an intervening sequence > point mean that the behavior of the program is undefined; ... True, and writing code that can cause undefined behavior is generally a Bad Thing. But it doesn't seem like such a bad thing to deliberately use undefined behavior when trying to figure out what an implementation is up to "under the hood". Just don't assume too much -- after all, the compiler might choose left-to-right order in one case, but not in another case, for efficiency reasons. >...it > could legitimately print "a suffusion of yellow" or cause your > keyboard to explode. True, according to the C standard. But I'm pretty sure that there's some other standard that will prevent it from blowing up my keyboard. ;-) By the way, when explaining what "undefined behavior" means, why does everybody choose a spectacular example, like exploding keyboards, or seg faults? I think the worst thing of all is when undefined behavior does exactly what you want it to do, leaving a latent bug that will rear its ugly head years later, when you change some code totally unrelated to the bug, or upgrade your compiler, or... >...(C's "undefined behavior" is very much like > Ada's "erroneous execution" -- and IMHO C chose a better term to > describe it.) "very much like"? Is there any difference at all? (Other than the fact that C has more of it, I mean.) I agree on the terms. An even better term, IMHO, would be "unpredictable behavior". > Furthermore, the order of evaluation of the argument expressions > isn't *necessarily* related to the order in which the results are > pushed onto the stack (assuming there even is a stack). There must be a stack. But you're right -- parameters might be passed in registers, or some other way, and there's no reason to assume that the evaluation order will match the way they're passed. - Bob