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: g2news2.google.com!news4.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.ada Subject: Re: Pascal Calling Convention Date: Fri, 25 Mar 2011 10:51:26 -0700 Organization: None to speak of Message-ID: References: <9b04626e-567d-408c-aab3-39b964b3ffd6@l2g2000prg.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx01.eternal-september.org; posting-host="mytEQcPL+ceHcrnNa7VoaQ"; logging-data="22968"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18A84VJUIFqupQSuwHD4cwc" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:95r1dqRw1dZRzsRINIBphBdFU8Q= sha1:+etYL34J+EyZfgP37Lc5lv05TnI= Xref: g2news2.google.com comp.lang.ada:19426 Date: 2011-03-25T10:51:26-07:00 List-Id: Robert A Duff writes: > 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. Keep in mind that "undefined" behavior doesn't just mean that the code will do one of N reasonable things. It means that the compiler is permitted to *assume*, for the sake of optimization, that no undefined behavior will occur during the execution of the program. This particular case is relatively straightforward, but there have been some serious bugs caused by this kind of thing. One example that springs to mind: some code read from uninitialized memory as a source of entropy for pseudo-random number generation (not the only source). That seems like a reasonable thing to do, but the compiler optimized away the code that did the reading, resulting in some really bad "random" numbers. >>...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. > ;-) Or from blowing up your rocket? > 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... Agreed. >>...(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.) There's no actual difference that I'm aware of. I was just being cautious. > I agree on the terms. An even better term, IMHO, would be > "unpredictable behavior". Except that there's no requirement that the behavior must be unpredictable. An implementer is free to define the behavior of some construct whose behavior is not defined by the language standard. At least in C, this is a common way to provide extensions. >> 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. We've had some lengthy arguments about this over in comp.lang.c. Yes, an implementation for a language that supports recursion must have a stack, in sense of a last-in first-out data structure for activation records. But the word "stack" is also used to refer to a contiguous chunk of memory whose "top" is indicated by the address stored in a "stack pointer". The stack is grown or shrunk by adding to or subtracting from the stack pointer (not necessarily respectively). The last-in first-out "stack" of activation records is implemented using this kind of hardware stack on almost all implementations of both C and Ada -- but neither language standard requires that it must be done this way. For example, I've heard about IBM mainframe implementations in which each new activation record is allocated from something like a heap, so there's no necessary relationship among the addresses of local variables for successive calls. I note that the word "stack" doesn't even appear in the C standard, which manages to describe function calling without using the concept. Ada refers in passing to stacks for tasks an interrupts; I'm not sure what kind of requirement that imposes. I have no doubt that you're aware of all this, but some readers might interpret your (quite correct) statement that "There must be a stack" to mean that there must be a contiguous hardware stack, managed via a stack pointer register, that grows and shrinks linearly in memory. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"