Argthtjtr

#include <stdlib.h>

#include <stdio.h>

#include <string.h>

#define TEXT "Good luck on this test"

int main () {

  char* cPtr = (char*)malloc(sizeof(TEXT));

  strncpy(cPtr,TEXT,sizeof(TEXT));

  printf("%sn",cPtr);

  free(cPtr);

  return(EXIT_SUCCESS);

}

1. The memory for variable cPtr?


2. The address to which cPtr points?


3. The code for malloc()?


4. The code that malloc() calls to move the brk pointer for the
   process running this program?

I think its:

1. Heap


2. Stack


3. Data segment


4. Shared library memory

Is it correct?

The only true answer is, wherever the compiler feels like. That's probably not the answer you want, so let's examine what a reasonable compiler would probably choose.

1. 
   cPtr would probably not be stored in memory at all. It fits in a register (pointers almost always fit in CPU registers), and you never take its address, so it will probably be located in one or more registers. It might be written to stack and then read back to preserve its value across the strncpy and printf calls, or its value may be preserved in some other way. (Note that the compiler doesn't need to preserve its value after the free call, since you never use it again.)


2. 
   malloc will almost always return a heap pointer, since that's where allocating dynamic memory is the easiest, if not the only possible location. So the buffer will be in the heap.


3. The compiler has a choice here. It might reference a linked malloc from some shared library, in which case it will reside in shared library code, or it might just inline all or part of the function, in which case some or all of it might reside in your program's code.


4. This assumes a POSIX environment. In every such environment I know, this is handled by a system call, sbrk. Thus, this code will reside within the operating system's kernel code.

EDIT: since some people mentioned the static string, "Good luck on this test", I figured discussing that one would be worthwhile as well. This string appears in three contexts:

• as a macro replacement (through #define), which is handled by the preprocessor before compiling, and thus doesn't go anywhere at all in the final output;


• as an argument to the strncpy function, in which case it is included as read-only data, either together with the program's executable code or in a separate section made exclusively for read-only data;


• as an argument to the sizeof operator. This is the most interesting case of the three. Technically, it should be equivalent to the previous one; however, many compilers can statically calculate the size of a constant string (it's very straightforward, after all), and thus they can replace sizeof(TEXT) with a plain 23 and avoid emitting the string altogether (for that occurrence).

It's actually a bit of a leading question, because it presumes that everything will be in memory.

Local variables, as well as temporary values without a name, are only placed on the stack if necessary. There are different reasons why that might be necessary, for example:

• The compiler is dumb or made to act dumb by compiling at the lowest possible optimization level.


• The target machine has an odd architecture without (or very few) registers (rare).


• There are too many local variables and temporary values live simultaneously to fit them all into registers at that point in the program, so some of them get "spilled". Being spilled is not a property of a variable exactly, but rather of a specific live range. In some sense a variable can therefore move around (if it has multiple associated live ranges and they get allocated differently) and even be in multiple places simultaneously (depending on how you count temporary copies, or unambiguously when loop unrolling is involved).


• The address of the local variable is taken and used in such a way that the compiler cannot prove that the variable does not need to be in memory (may induce live range splitting so the variable is only actually in memory temporarily).

Most likely none of the above apply (the last item definitely does not apply, the address is not taken) so we should expect cPtr to spend its entire lifetime in registers.

Testing it out on clang targeting x64 we might get code like this:

main:                                   # @main

    push    rbx

    mov     edi, 23

    call    malloc

    mov     rbx, rax



    ; at this point, rbx roughly corresponds to cPtr

    ; it's also still in rax but rax is overwritten by the next operation



    movabs  rax, 32777976875610985 ; btw this weird number is a piece of string

    mov     qword ptr [rbx + 15], rax

    movups  xmm0, xmmword ptr [rip + .L.str]

    movups  xmmword ptr [rbx], xmm0



    ; rbx (cPtr) is copied to rdi in order to give it to puts as argument



    mov     rdi, rbx

    call    puts

    mov     rdi, rbx

    call    free

    xor     eax, eax

    pop     rbx

    ret

.L.str:

    .asciz  "Good luck on this test"

Targeting MIPS or ARM or PowerPC with eg GCC shows a similar pattern of cPtr not being on the stack but in a register (or several registers, depending on how you count), though of course the code looks pretty different.

A fun detail of the code above is that while the entire string does appear in a data segment (rodata), a piece of it also appears in the code segment as the immediate operand of that movabs.

1. Stack


2. Heap


3. Data


4. Shared library

That is how i would answer this question.

1. char * cPtr = NULL; declares a char * on the stack and assigns it to point to NULL, In your instance the malloc() assignes it to point to heap memory but the cPtr variable itself is on the stack.




2. Malloc allocates heap memory.




3. The TEXT string is in data segment, and sizeof ("TEXT STRING") will be handled as an operator to an address in data segment. I assume your question means the "code for the arguments to malloc"




4. Your code doesnt define the function malloc so whatever its doing must be happening due to one of the libraries you #included.

I may be wrong on one or more of these answers but that is my understanding. If someone can tell me where I am wrong ill correct the answer.