do arguments passed into a function always occupy contiguous memory?

This is a discussion on do arguments passed into a function always occupy contiguous memory? within the C++ Programming forums, part of the General Programming Boards category; empirical evidence points to 'yes', but i'd be surprised if there weren't exceptions (myriad calling conventions, etc.). anyone care to ...

  1. #1
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839

    do arguments passed into a function always occupy contiguous memory?

    empirical evidence points to 'yes', but i'd be surprised if there weren't exceptions (myriad calling conventions, etc.). anyone care to share some arcane knowledge?

  2. #2
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    I would guess that when the program initializes memory is reserved for all functions and there local variables. Which included parameters-variable, which will copy the value of the parameters passed. So, there is no point not having contiguous memory for each function. But in any case, I would assume that whatever goes for the main function goes for every function. If for example, the OS cannot reserve contiguous memory for a function, it won't. It will have to provide another mechanism for the separate memory chunks. But this would apply for the main funciton also. In general, the whole program is a bunch of instructions, nothing else. The functions are also included in the main program. Meaning that the executable file has all the information needed and takes a certain amount in RAM when executed, including all the variables and memory allocated statically. If it needs more memory it has to dynamically allocate it. Right?

  3. #3
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    i think i understood all that, but honestly i don't see how that directly answers the question...

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,450
    Why do you ask? I have a feeling that the answer is yes in practice, but no in theory since I do not believe that the C++ standard mandates anything about this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    i'm experimenting with techniques for function signature obfuscation and subsequent recovery

    looking at the source for cstdarg, variadic functions must have their arguments passed as a contiguous block of memory

    i recall, however, that certain calling conventions such as stdcall are incompatible with variadic function arguments.

  6. #6
    Registered User
    Join Date
    Nov 2009
    Posts
    82
    It didn't sound like a direct answer because it isn't a direct answer and you won't get a direct answer, unless your asking about a very specific physical/operating system. Why? They're not all the same, who knows what some do. The bottom line comes down to guaranteeing functionality which does not require any specific memory allocation distribution other than what meets functional requirements. I can't say with certainty myself, but I have an idea of what it's likely to be.

    I do think it is contiguous if *I had to guess, to an extent. Specifically function arguments? Yes and no actually. The space allocation for the function input would be I assume, the pointer you pass to the function could be copied from anywhere though...

    This is more of a hardware and OS design question than it is programming language specific. imo~
    Last edited by since; 12-04-2009 at 08:54 AM.

  7. #7
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    looking at the source for cstdarg, variadic functions must have their arguments passed as a contiguous block of memory
    it seems to be compiler-dependent at worst.

  8. #8
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,236
    Most stack-based calling conventions will have all the parameters in a contiguous block. There's no reason to do otherwise, although technically, the compiler could place the params on Mars if it wanted to.

    The most realistic violation of this would be register call, where params aren't even IN memory, and other hand-coded calls, like passing parameters in global variables.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #9
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    I don't understand this question. Arguments are passed on the stack. In every 32-bit x86 PM application the first parameter to a function starts at EBP + 8. Here is the stack frame at the entrypoint of every 32-bit x86 protected mode function. Real mode differs somewhat from this layout.

    EBP + 8 - first parameter starts here
    EBP + 4 - Caller's address
    EBP - Previous value of ebp
    EBP - 4 - first local variable

    The order in which params appear depends on the order in which they are pushed onto the stack.

    Calling convention does determine the order in which the params are passed (left to right, right to left) but it really has more to do with who is responsible for cleaning up the stack before returning. If the calling conventions get mixed up or mistmatched then one function will expect the caller to clean up and the caller will expect the callee to clean up. This will definitely cause a stack overflow. However if the calling conventions are mismatched on the order of params it is quite likely the code will crash so it is important to understand which calling convention is being used. I had the wonderful privilege of debugging an error such as this which required looking at a lot of assembly code since the epilogue to a function is not in C/C++.

    As to whether these occupy contiguous memory is really not important. It is important to know where to get them.
    Last edited by VirtualAce; 12-04-2009 at 05:33 PM.

  10. #10
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,236
    Quote Originally Posted by Bubba View Post
    Calling convention does determine the order in which the params are passed (left to right, right to left) but it really has more to do with who is responsible for cleaning up the stack before returning.
    You're assuming the stack is even involved in parameter passing. For register calling conventions all parameters might fit in registers and no stack space at all is used for parameters.

    If the compiler can prove that the program does not contain any recursion, it can completely eliminate the stack altogether. I don't know of any compiler that does that, but it's not outside the realm of possibility.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    You're assuming the stack is even involved in parameter passing. For register calling conventions all parameters might fit in registers and no stack space at all is used for parameters.

    If the compiler can prove that the program does not contain any recursion, it can completely eliminate the stack altogether. I don't know of any compiler that does that, but it's not outside the realm of possibility.
    In most cases the stack is used but you are correct there is nothing to say it has to be. As far as my 12 mile horizon goes the stack is where they are passed. I rarely, if ever, see the register calling convention used. However I will freely admit it definitely is a valid use case and my statement does not take it into account.

  12. #12
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    btw, while this was an interesting topic to look into, i found a much better way to deal with the problem; namely, not to obfuscate function signatures

    i was trying to contain heterogenous function signatures as abstract functors in containers.

    the problem? references! since i wanted to contain a reference to an argument type, i had a combinatorial-growth of the number of partial specializations i had to code with respect to the number of arguments, or else i woudl receive a "can't define a &&" error.

    the (imo clever) solution was to create an intermediate template variable class with implicit conversion between it and it's template parameter type. then all i ahd to do was specialize that for T and T&

  13. #13
    Registered User slingerland3g's Avatar
    Join Date
    Jan 2008
    Location
    Seattle
    Posts
    602
    *nix systems mind you:


    Every function except inline and or static functions implement a stack frame of which is a block of contiguous addresses. Though I think x64 bases systems may implement this differently with their use of GPRs ( not sure they are contiguous across all arguments being passed through, as they can be split across these two areas of memory mappings)

    All of this and how the stack works I got from reading up on "Self Service Linux - Mastering the art of problem determination"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. In over my head
    By Shelnutt2 in forum C Programming
    Replies: 1
    Last Post: 07-08-2008, 06:54 PM
  2. Including lib in a lib
    By bibiteinfo in forum C++ Programming
    Replies: 0
    Last Post: 02-07-2006, 01:28 PM
  3. Game Pointer Trouble?
    By Drahcir in forum C Programming
    Replies: 8
    Last Post: 02-04-2006, 01:53 AM
  4. Replies: 10
    Last Post: 09-27-2005, 12:49 PM
  5. Problem with Visual C++ Object-Oriented Programming Book.
    By GameGenie in forum C++ Programming
    Replies: 9
    Last Post: 08-29-2005, 11:21 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21