Answers.Body: <p>As Gypsy Spellweaver suggested, I posted the question to StackOverflow. It turns out the first 8 int / pointer parameters can get passed via registers rather than via the stack.
  <a href="https://stackoverflow.com/questions/19351451/printf-arguments-not-pushed-on-the-stack">Printf arguments not passed on the stack</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-05-09T23:08:14.390Z
Answers.Text: That is the calling convention on x86-64. Others may differ. The "take the variable's address" forces the compiler to give it a place in memory so there is an address to take. A *truly* smart compiler may even figure out nothing useful is done with the variable through the pointer, and put each in turn at the very same spot.
Answers.UserDisplayName: vonbrand
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-04T19:03:46.470Z
Answers.LastActivityDate: 2021-02-04T19:03:46.470Z
Answers.UserDisplayName: Bryan R
Answers.Body: <p>Why not. It is totally arbitrary. There may be no reason. It has to be one way, it is useful to be consistent. But there are many many orders even <code>c1, b1, e1, e1, a1</code>, are any other order. The <code>C</code> standard makes no guarantee. However it does say that it a lot of circumstances you can get a pointer to a variable. It says that you can use a pointer to traverse an array. However it says that it is <strong>undefined</strong> what is beyond the variable or array. You <strong>can not</strong> know the relative address of one variable from another, as the offset is <strong>undefined</strong>. I think relative position within structures is <strong>implementation defined</strong>.</p>
  <p>Undefined means that it can change (change each time it is compiled).</p>
  <p>One reason that it may change, is a system called &quot;address space randomisation&quot;. It is a security measure, to make it harder to do a buffer overrun (and similar) attack, on buggy software.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-04T20:28:26.433Z
Answers.Text: A randomizer is less likely with a stack, though. There was once an implementation of (I think) BASIC that used a linked list for the stack.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-04T20:35:31.597Z
Answers.Text: Not that random. The stack from will still have to be in the same place, but the order of items in the frame can be randomised.Items in the stack of accessed with register offset addressing, so any change in order has to be matched with changes to the offsets in the assembler code. There is no run time cost in doing this, only compile time cost. All the variable mentioned (arguments and locals) are usually in the stack frame.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-04T20:09:18.500Z
Answers.LastActivityDate: 2021-02-04T20:09:18.500Z
Answers.UserDisplayName: ctrl-alt-delor
Answers.Body: <p>Depends on your machine (some ABIs decree the first few arguments -- of the right types -- are passed in registers, others say all go to the stack; but then again, some environments just diverge from what the machine's designer defined), on your compiler's whim (unless it has to match up with code written by others, it's up to it). A smart compiler may even decide that the function can be inlined, and thus make it dissappear completely.</p>
  <p>For one example of complex calling conventions, take a peek at Jorgensen's <a href="http://www.egr.unlv.edu/%7Eed/assembly64.pdf" rel="nofollow noreferrer">&quot;x86-64 assembly language programming with Ubuntu&quot;</a>, section 12.8 (page 171 et seq). And when you mix in varargs is when the real fun starts.</p>
  <p>Take a peek at e.g. the C standard: It is very careful to make clear that the order in which arguments are computed and stored is <em>not</em> defined by the language.</p>
  <p>In your experiment the variables are required to be copied into memory, because you take their addresses. In which order they are placed in memory by the compiler is <em>not</em> fixed by the language. The compiler might even pick the same location for some of them if it can prove that there is no use through the pointer before placing the next one there.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-04-09T22:50:10.960Z
Answers.LastActivityDate: 2021-05-09T23:17:33.003Z
Answers.LastEditDate: 2021-05-09T23:17:33.003Z
Answers.UserDisplayName: vonbrand
Answers.Body: <p>I haven't delved into the details, but if a language doesn't define its own implementation (few do) then the implementation will vary depending on the architecture for which it is compiled. It will also vary over time as research provides hints and clues about efficiency (both compile time and run time efficiency).</p>
  <p>So, one stack protocol might be appropriate for one architecture, but wildly inefficient on another, depending on the registers available for the stack as well as, perhaps, paging systems, and all the rest. So, the implementer will take advantage of whatever hardware is available on the machine of interest.</p>
  <p>The normally thought of &quot;normal&quot; architecture (register-transfer) disappeared in the 60's or so. It is fun to think about and to simulate, but not especially realistic. C was designed originally for the PDP-7 architecture, which is pretty much obsolete.</p>
  <p>Also, if a compiler uses some top-down techniques derived from LL processing as well as more &quot;normal for C&quot; bottom up processing, the parameters, in particular might wind up in a different order. For example, a compiler might use an intermediate language that is itself compiled and who can say what the characteristics of that intermediate language might be.</p>
  <p>It doesn't affect your question, I think, but heap implementations might differ wildly between implementations.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-04T17:28:50.080Z
Answers.LastActivityDate: 2021-02-04T17:36:36.867Z
Answers.LastEditDate: 2021-02-04T17:36:36.867Z
Answers.UserDisplayName: Buffy
Body: <p>Several years ago, I put together this little memory address exploration for my students to help them to understand pointers, arrays, the stack, and the heap.</p>
  <p>I just compiled and ran it in a new environment (gcc on a AWS Linux server) and the order of the parameters for <strong>foo</strong> are different from what I would expect. The local function variables (d1 and e1) now have a higher address in comparison to the function parameters (a1, b1, and c1).</p>
  <p>The addresses for the parameters / variables in function <strong>foo</strong> are listing as:</p>
  <blockquote>
  <pre><code>&amp;a1: fa2740fc
  &amp;b1: fa2740f0
  &amp;c1: fa2740e8
  &amp;d1: fa27410c
  &amp;e1: fa274100
  </code></pre>
  </blockquote>
  <p>Any thoughts on why variables <em>d1</em> and <em>e1</em> have higher addresses than <em>a1</em>, <em>b1</em>, and <em>c1</em>?</p>
  <pre><code>#include &lt;stdio.h&gt;
  #include &lt;stdlib.h&gt;
  #include &lt;string.h&gt;
  
  int* foo (int a1, int b1[], int *c1)
  {
    int d1 = *c1 + a1;
    int *e1;
    
    e1 = malloc (sizeof(int));
  
    printf (&quot;5) Addresses of arguments/variables of foo:\n&quot;);
    printf (&quot;   Update your stack sketch.\n&quot;);
    printf (&quot;     &amp;a1: %x\n&quot;, &amp;a1);
    printf (&quot;     &amp;b1: %x\n&quot;, &amp;b1);
    printf (&quot;     &amp;c1: %x\n&quot;, &amp;c1);
    printf (&quot;     &amp;d1: %x\n&quot;, &amp;d1);
    printf (&quot;     &amp;e1: %x\n\n&quot;, &amp;e1);
  
    printf (&quot;6) Values of arguments/variables in foo:\n&quot;);
    printf (&quot;   Include these on your stack sketch as well.\n&quot;);
    printf (&quot;     a1: %x\n&quot;, a1);
    printf (&quot;     b1: %x\n&quot;, b1);
    printf (&quot;     c1: %x\n&quot;, c1);
    printf (&quot;     d1: %x\n&quot;, d1);
    printf (&quot;     e1: %08x\n\n&quot;, e1);
  
    printf (&quot;7) *c1 == %x, why?  Explain using your stack drawing.\n\n&quot;, *c1); 
    
    printf (&quot;8) e1 is a reference to an integer, much like c1.  Why is e1 so\n &quot;);
    printf (&quot;   different in value?\n\n&quot;);
  
    return e1;
  }
  
  
  int main ()
  {
    int a = 5;
    int b[] = {8, 14, -7, 128, 12};
    int c = 10;
    int d = 14;
  
    printf (&quot;1) Locations...\n&quot;);
    printf (&quot;   Use these locations to sketch the stack.\n&quot;);
    printf (&quot;     &amp;a: %x\n&quot;, &amp;a);
    printf (&quot;     &amp;b: %x\n&quot;, &amp;b);
    printf (&quot;     &amp;c: %x\n&quot;, &amp;c);
    printf (&quot;     &amp;d: %x\n\n&quot;, &amp;d);
    
    printf (&quot;2a) Values:\n&quot;);
    printf (&quot;   Why does b != 8?\n&quot;);
    printf (&quot;     a: %x\n&quot;, a);
    printf (&quot;     b: %x\n&quot;, b);
    printf (&quot;     c: %x\n&quot;, c);
    printf (&quot;     d: %x\n\n&quot;, d);
  
    printf (&quot;2b) Values:\n&quot;);
    printf (&quot;   What memory address is *b accessing?\n&quot;);
    printf (&quot;     *b: %x\n\n&quot;, *b);
    
    printf (&quot;3) Notice that the following increase by 4 each, why?\n&quot;);
    printf (&quot;     &amp;(b[0]): %x\n&quot;, &amp;(b[0]));
    printf (&quot;     &amp;(b[1]): %x\n&quot;, &amp;(b[1]));
    printf (&quot;     &amp;(b[2]): %x\n&quot;, &amp;(b[2]));
    printf (&quot;     &amp;(b[3]): %x\n\n&quot;, &amp;(b[3]));
  
    printf (&quot;4) Pointers can be added, but the addition might have interesting results.\n&quot;);
    printf (&quot;   Explain why b + 1 != b + 1 in the normal way of thinking about addition.\n&quot;);
    printf (&quot;     b:   %x\n&quot;, b);
    printf (&quot;     b+1: %x\n&quot;, b+1);
    printf (&quot;     b+2: %x\n&quot;, b+2);
    printf (&quot;     b+3: %x\n\n&quot;, b+3);
    
    foo (a, b, &amp;c);
  }
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-04T16:06:30.583Z
Comments.Text: An interesting experiment. I have no answers, and merely a guess that it's a compiler optimization of some kind. Rather I have a suggestion for how to get a good answer. I'm not sure of the reception there, but you're more likely to get expert insight by asking the question on StackOverflow, where you already have an account anyway.
Comments.UserDisplayName: Gypsy Spellweaver
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-04T16:45:33.923Z
Comments.Text: local variables `d1` and `e`?  You said `d` and `e`, but `d` appears to be in `main`.
Comments.UserDisplayName: Ben I.
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-04T17:08:22.573Z
Comments.Text: Thank you Ben, I updated the variable names.
Comments.UserDisplayName: Bryan R
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-05T15:21:54.967Z
Comments.Text: FYI: In an abstract sense, the call stack is a stack of data objects known as [_activation records_](https://en.wikipedia.org/wiki/Call_stack#ACTIVATION-RECORD) (a.k.a., "activation frames," "stack frames," etc.) Each one holds the state of one "activation" (a.k.a., "call to") a function. Activation records can take many forms. If I remember correctly, in the [Self programming language](https://en.wikipedia.org/wiki/Self_(programming_language)), Activation records actually were allocated from the heap, and they were first-class objects that could be manipulated just like any other object.
Comments.UserDisplayName: Solomon Slow
Tags: <c>
Title: Order of parameter / variables on stack in C
ThreadText: # Order of parameter / variables on stack in C
  
  (Asked by: username_0 on 2021-02-04)
  
  Several years ago, I put together this little memory address exploration for my students to help them to understand pointers, arrays, the stack, and the heap.
  
  I just compiled and ran it in a new environment (gcc on a AWS Linux server) and the order of the parameters for **foo** are different from what I would expect. The local function variables (d1 and e1) now have a higher address in comparison to the function parameters (a1, b1, and c1).
  
  The addresses for the parameters / variables in function **foo** are listing as:
  
  > ```
  > &a1: fa2740fc
  > &b1: fa2740f0
  > &c1: fa2740e8
  > &d1: fa27410c
  > &e1: fa274100
  >
  > ```
  
  Any thoughts on why variables *d1* and *e1* have higher addresses than *a1*, *b1*, and *c1*?
  
  ```
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  
  int* foo (int a1, int b1[], int *c1)
  {
    int d1 = *c1 + a1;
    int *e1;
    
    e1 = malloc (sizeof(int));
  
    printf ("5) Addresses of arguments/variables of foo:\n");
    printf ("   Update your stack sketch.\n");
    printf ("     &a1: %x\n", &a1);
    printf ("     &b1: %x\n", &b1);
    printf ("     &c1: %x\n", &c1);
    printf ("     &d1: %x\n", &d1);
    printf ("     &e1: %x\n\n", &e1);
  
    printf ("6) Values of arguments/variables in foo:\n");
    printf ("   Include these on your stack sketch as well.\n");
    printf ("     a1: %x\n", a1);
    printf ("     b1: %x\n", b1);
    printf ("     c1: %x\n", c1);
    printf ("     d1: %x\n", d1);
    printf ("     e1: %08x\n\n", e1);
  
    printf ("7) *c1 == %x, why?  Explain using your stack drawing.\n\n", *c1); 
    
    printf ("8) e1 is a reference to an integer, much like c1.  Why is e1 so\n ");
    printf ("   different in value?\n\n");
  
    return e1;
  }
  
  int main ()
  {
    int a = 5;
    int b[] = {8, 14, -7, 128, 12};
    int c = 10;
    int d = 14;
  
    printf ("1) Locations...\n");
    printf ("   Use these locations to sketch the stack.\n");
    printf ("     &a: %x\n", &a);
    printf ("     &b: %x\n", &b);
    printf ("     &c: %x\n", &c);
    printf ("     &d: %x\n\n", &d);
    
    printf ("2a) Values:\n");
    printf ("   Why does b != 8?\n");
    printf ("     a: %x\n", a);
    printf ("     b: %x\n", b);
    printf ("     c: %x\n", c);
    printf ("     d: %x\n\n", d);
  
    printf ("2b) Values:\n");
    printf ("   What memory address is *b accessing?\n");
    printf ("     *b: %x\n\n", *b);
    
    printf ("3) Notice that the following increase by 4 each, why?\n");
    printf ("     &(b[0]): %x\n", &(b[0]));
    printf ("     &(b[1]): %x\n", &(b[1]));
    printf ("     &(b[2]): %x\n", &(b[2]));
    printf ("     &(b[3]): %x\n\n", &(b[3]));
  
    printf ("4) Pointers can be added, but the addition might have interesting results.\n");
    printf ("   Explain why b + 1 != b + 1 in the normal way of thinking about addition.\n");
    printf ("     b:   %x\n", b);
    printf ("     b+1: %x\n", b+1);
    printf ("     b+2: %x\n", b+2);
    printf ("     b+3: %x\n\n", b+3);
    
    foo (a, b, &c);
  }
  
  ```
  
  **Tags:** c
  
  > **Comments:**
  > **username_1**: An interesting experiment. I have no answers, and merely a guess that it's a compiler optimization of some kind. Rather I have a suggestion for how to get a good answer. I'm not sure of the reception there, but you're more likely to get expert insight by asking the question on StackOverflow, where you already have an account anyway.  
  > **username_2**: local variables `d1` and `e`?  You said `d` and `e`, but `d` appears to be in `main`.  
  > **username_0**: Thank you Ben, I updated the variable names.  
  > **username_3**: FYI: In an abstract sense, the call stack is a stack of data objects known as [_activation records_](https://en.wikipedia.org/wiki/Call_stack#ACTIVATION-RECORD) (a.k.a., "activation frames," "stack frames," etc.) Each one holds the state of one "activation" (a.k.a., "call to") a function. Activation records can take many forms. If I remember correctly, in the [Self programming language](https://en.wikipedia.org/wiki/Self_(programming_language)), Activation records actually were allocated from the heap, and they were first-class objects that could be manipulated just like any other object.  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_6 on 2021-02-04. Score: 6 | Accepted answer
  
  I haven't delved into the details, but if a language doesn't define its own implementation (few do) then the implementation will vary depending on the architecture for which it is compiled. It will also vary over time as research provides hints and clues about efficiency (both compile time and run time efficiency).
  
  So, one stack protocol might be appropriate for one architecture, but wildly inefficient on another, depending on the registers available for the stack as well as, perhaps, paging systems, and all the rest. So, the implementer will take advantage of whatever hardware is available on the machine of interest.
  
  The normally thought of "normal" architecture (register-transfer) disappeared in the 60's or so. It is fun to think about and to simulate, but not especially realistic. C was designed originally for the PDP-7 architecture, which is pretty much obsolete.
  
  Also, if a compiler uses some top-down techniques derived from LL processing as well as more "normal for C" bottom up processing, the parameters, in particular might wind up in a different order. For example, a compiler might use an intermediate language that is itself compiled and who can say what the characteristics of that intermediate language might be.
  
  It doesn't affect your question, I think, but heap implementations might differ wildly between implementations.
  
  
  ---
  
  ### Answer by username_0 on 2021-02-04. Score: 3
  
  As username_1 suggested, I posted the question to StackOverflow. It turns out the first 8 int / pointer parameters can get passed via registers rather than via the stack.
  [Printf arguments not passed on the stack](https://stackoverflow.com/questions/19351451/printf-arguments-not-pushed-on-the-stack)
  
  > **Comments:**
  > **username_4**: That is the calling convention on x86-64. Others may differ. The "take the variable's address" forces the compiler to give it a place in memory so there is an address to take. A *truly* smart compiler may even figure out nothing useful is done with the variable through the pointer, and put each in turn at the very same spot.  
  
  ---
  
  ### Answer by username_5 on 2021-02-04. Score: 1
  
  Why not. It is totally arbitrary. There may be no reason. It has to be one way, it is useful to be consistent. But there are many many orders even `c1, b1, e1, e1, a1`, are any other order. The `C` standard makes no guarantee. However it does say that it a lot of circumstances you can get a pointer to a variable. It says that you can use a pointer to traverse an array. However it says that it is **undefined** what is beyond the variable or array. You **can not** know the relative address of one variable from another, as the offset is **undefined**. I think relative position within structures is **implementation defined**.
  
  Undefined means that it can change (change each time it is compiled).
  
  One reason that it may change, is a system called "address space randomisation". It is a security measure, to make it harder to do a buffer overrun (and similar) attack, on buggy software.
  
  > **Comments:**
  > **username_6**: A randomizer is less likely with a stack, though. There was once an implementation of (I think) BASIC that used a linked list for the stack.  
  > **username_5**: Not that random. The stack from will still have to be in the same place, but the order of items in the frame can be randomised.Items in the stack of accessed with register offset addressing, so any change in order has to be matched with changes to the offsets in the assembler code. There is no run time cost in doing this, only compile time cost. All the variable mentioned (arguments and locals) are usually in the stack frame.  
  
  ---
  
  ### Answer by username_4 on 2021-04-09. Score: 1
  
  Depends on your machine (some ABIs decree the first few arguments -- of the right types -- are passed in registers, others say all go to the stack; but then again, some environments just diverge from what the machine's designer defined), on your compiler's whim (unless it has to match up with code written by others, it's up to it). A smart compiler may even decide that the function can be inlined, and thus make it dissappear completely.
  
  For one example of complex calling conventions, take a peek at Jorgensen's ["x86-64 assembly language programming with Ubuntu"](http://www.egr.unlv.edu/%7Eed/assembly64.pdf), section 12.8 (page 171 et seq). And when you mix in varargs is when the real fun starts.
  
  Take a peek at e.g. the C standard: It is very careful to make clear that the order in which arguments are computed and stored is *not* defined by the language.
  
  In your experiment the variables are required to be copied into memory, because you take their addresses. In which order they are placed in memory by the compiler is *not* fixed by the language. The compiler might even pick the same location for some of them if it can prove that there is no use through the pointer before placing the next one there.
  
  
  ---
  
  