Where the following objects are stored in memory?

#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);

}

The memory for variable cPtr?

The address to which cPtr points?

The code for malloc()?

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

I think its:

Heap

Stack

Data segment

Shared library memory

Is it correct?

edited Nov 19 '18 at 23:56

Dennis Vash

571316

asked Nov 19 '18 at 23:21

Harold L

I don't believe 3. is correct. The TEXT macro would be stored in the data segment though.

– Patrick Roberts
Nov 19 '18 at 23:24

1

Some systems don't have a heap or a stack

– M.M
Nov 19 '18 at 23:25

1

An answer to this question would be platform specific.

– VTT
Nov 19 '18 at 23:29

2

I think 1 and 2 are backwards. char *cPtr is on the stack. "The address to which cPtr points" sounds like they're asking about the memory allocated by malloc; that's on the heap.

– Schwern
Nov 19 '18 at 23:30

1

Nothing in the C/C++ standard mandates that anything must end on the stack, or even that the thing known as “stack” exists. You need to look in the assembly output to see what happens, as all of it is implementation-defined. I.e. the question should also state what exact compiler is spoken about, and what compiler options.

– Kuba Ober
Nov 20 '18 at 3:04

|
show 5 more comments

#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);

}

The memory for variable cPtr?

The address to which cPtr points?

The code for malloc()?

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

I think its:

Heap

Stack

Data segment

Shared library memory

Is it correct?

edited Nov 19 '18 at 23:56

Dennis Vash

571316

asked Nov 19 '18 at 23:21

Harold L

I don't believe 3. is correct. The TEXT macro would be stored in the data segment though.

– Patrick Roberts
Nov 19 '18 at 23:24

1

Some systems don't have a heap or a stack

– M.M
Nov 19 '18 at 23:25

1

An answer to this question would be platform specific.

– VTT
Nov 19 '18 at 23:29

2

I think 1 and 2 are backwards. char *cPtr is on the stack. "The address to which cPtr points" sounds like they're asking about the memory allocated by malloc; that's on the heap.

– Schwern
Nov 19 '18 at 23:30

1

Nothing in the C/C++ standard mandates that anything must end on the stack, or even that the thing known as “stack” exists. You need to look in the assembly output to see what happens, as all of it is implementation-defined. I.e. the question should also state what exact compiler is spoken about, and what compiler options.

– Kuba Ober
Nov 20 '18 at 3:04

|
show 5 more comments

#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);

}

The memory for variable cPtr?

The address to which cPtr points?

The code for malloc()?

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

I think its:

Heap

Stack

Data segment

Shared library memory

Is it correct?

edited Nov 19 '18 at 23:56

Dennis Vash

571316

asked Nov 19 '18 at 23:21

Harold L

#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);

}

The memory for variable cPtr?

The address to which cPtr points?

The code for malloc()?

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

I think its:

Heap

Stack

Data segment

Shared library memory

Is it correct?

edited Nov 19 '18 at 23:56

Dennis Vash

571316

asked Nov 19 '18 at 23:21

Harold L

edited Nov 19 '18 at 23:56

Dennis Vash

571316

asked Nov 19 '18 at 23:21

Harold L

edited Nov 19 '18 at 23:56

Dennis Vash

571316

edited Nov 19 '18 at 23:56

Dennis Vash

571316

edited Nov 19 '18 at 23:56

Dennis Vash

571316

asked Nov 19 '18 at 23:21

Harold L

asked Nov 19 '18 at 23:21

Harold L

asked Nov 19 '18 at 23:21

Harold L

I don't believe 3. is correct. The TEXT macro would be stored in the data segment though.

– Patrick Roberts
Nov 19 '18 at 23:24

1

Some systems don't have a heap or a stack

– M.M
Nov 19 '18 at 23:25

1

An answer to this question would be platform specific.

– VTT
Nov 19 '18 at 23:29

2

I think 1 and 2 are backwards. char *cPtr is on the stack. "The address to which cPtr points" sounds like they're asking about the memory allocated by malloc; that's on the heap.

– Schwern
Nov 19 '18 at 23:30

1

Nothing in the C/C++ standard mandates that anything must end on the stack, or even that the thing known as “stack” exists. You need to look in the assembly output to see what happens, as all of it is implementation-defined. I.e. the question should also state what exact compiler is spoken about, and what compiler options.

– Kuba Ober
Nov 20 '18 at 3:04

|
show 5 more comments

I don't believe 3. is correct. The TEXT macro would be stored in the data segment though.

– Patrick Roberts
Nov 19 '18 at 23:24

1

Some systems don't have a heap or a stack

– M.M
Nov 19 '18 at 23:25

1

An answer to this question would be platform specific.

– VTT
Nov 19 '18 at 23:29

2

I think 1 and 2 are backwards. char *cPtr is on the stack. "The address to which cPtr points" sounds like they're asking about the memory allocated by malloc; that's on the heap.

– Schwern
Nov 19 '18 at 23:30

1

Nothing in the C/C++ standard mandates that anything must end on the stack, or even that the thing known as “stack” exists. You need to look in the assembly output to see what happens, as all of it is implementation-defined. I.e. the question should also state what exact compiler is spoken about, and what compiler options.

– Kuba Ober
Nov 20 '18 at 3:04

I don't believe 3. is correct. The TEXT macro would be stored in the data segment though.

– Patrick Roberts
Nov 19 '18 at 23:24

Some systems don't have a heap or a stack

– M.M
Nov 19 '18 at 23:25

An answer to this question would be platform specific.

– VTT
Nov 19 '18 at 23:29

I think 1 and 2 are backwards. char *cPtr is on the stack. "The address to which cPtr points" sounds like they're asking about the memory allocated by malloc; that's on the heap.

– Schwern
Nov 19 '18 at 23:30

Nothing in the C/C++ standard mandates that anything must end on the stack, or even that the thing known as “stack” exists. You need to look in the assembly output to see what happens, as all of it is implementation-defined. I.e. the question should also state what exact compiler is spoken about, and what compiler options.

– Kuba Ober
Nov 20 '18 at 3:04

|
show 5 more comments

3 Answers
3

active

oldest

votes

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.

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.)

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.

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.

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).

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:20

aaaaaa123456789

3,1491227

+1, but your last bullet about sizeof(TEXT) sounds like you're thinking of strlen, though: sizeof is compile time except for variable length arrays.

– Rup
Nov 20 '18 at 7:01

@Rup I'm not sure if this is true for all versions of C, though.

– aaaaaa123456789
Nov 20 '18 at 7:46

add a comment |

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.

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:24

harold

41.3k357108

add a comment |

-1

Stack

Heap

Data

Shared library

That is how i would answer this question.

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.

Malloc allocates heap memory.

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"

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.

answered Nov 19 '18 at 23:42

Bwebb

3358

Thanks for the down-vote without any comment! It really helps me fix my answer.

– Bwebb
Nov 20 '18 at 1:18

1

Read other answers to understand what’s wrong. But in general, it’s misguided to talk about what a compiler might do: have you actually looked at what it does, or are you making stuff up? Have you ever checked how well you can predict what a compiler does by writing code, predicting, and checking actual output? You should well get the compiler and look at its output. It’s not magic. Godbolt compiler explorer exists for a reason: so that people don’t have to guess, as such guesses are incorrect more often than not.

– Kuba Ober
Nov 20 '18 at 3:07

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384055%2fwhere-the-following-objects-are-stored-in-memory%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

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.

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.)

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.

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.

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).

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:20

aaaaaa123456789

3,1491227

+1, but your last bullet about sizeof(TEXT) sounds like you're thinking of strlen, though: sizeof is compile time except for variable length arrays.

– Rup
Nov 20 '18 at 7:01

@Rup I'm not sure if this is true for all versions of C, though.

– aaaaaa123456789
Nov 20 '18 at 7:46

add a comment |

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.

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.)

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.

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.

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).

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:20

aaaaaa123456789

3,1491227

+1, but your last bullet about sizeof(TEXT) sounds like you're thinking of strlen, though: sizeof is compile time except for variable length arrays.

– Rup
Nov 20 '18 at 7:01

@Rup I'm not sure if this is true for all versions of C, though.

– aaaaaa123456789
Nov 20 '18 at 7:46

add a comment |

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.

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.)

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.

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.

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).

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:20

aaaaaa123456789

3,1491227

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.

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.)

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.

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.

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).

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:20

aaaaaa123456789

3,1491227

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:20

aaaaaa123456789

3,1491227

answered Nov 20 '18 at 0:20

aaaaaa123456789

3,1491227

answered Nov 20 '18 at 0:20

aaaaaa123456789

3,1491227

+1, but your last bullet about sizeof(TEXT) sounds like you're thinking of strlen, though: sizeof is compile time except for variable length arrays.

– Rup
Nov 20 '18 at 7:01

@Rup I'm not sure if this is true for all versions of C, though.

– aaaaaa123456789
Nov 20 '18 at 7:46

add a comment |

+1, but your last bullet about sizeof(TEXT) sounds like you're thinking of strlen, though: sizeof is compile time except for variable length arrays.

– Rup
Nov 20 '18 at 7:01

@Rup I'm not sure if this is true for all versions of C, though.

– aaaaaa123456789
Nov 20 '18 at 7:46

+1, but your last bullet about sizeof(TEXT) sounds like you're thinking of strlen, though: sizeof is compile time except for variable length arrays.

– Rup
Nov 20 '18 at 7:01

@Rup I'm not sure if this is true for all versions of C, though.

– aaaaaa123456789
Nov 20 '18 at 7:46

add a comment |

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"

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.

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:24

harold

41.3k357108

add a comment |

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"

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.

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:24

harold

41.3k357108

add a comment |

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"

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.

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:24

harold

41.3k357108

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"

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.

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:24

harold

41.3k357108

edited Nov 20 '18 at 0:29

answered Nov 20 '18 at 0:24

harold

41.3k357108

answered Nov 20 '18 at 0:24

harold

41.3k357108

answered Nov 20 '18 at 0:24

harold

41.3k357108

add a comment |

-1

Stack

Heap

Data

Shared library

That is how i would answer this question.

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.

Malloc allocates heap memory.

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"

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.

answered Nov 19 '18 at 23:42

Bwebb

3358

Thanks for the down-vote without any comment! It really helps me fix my answer.

– Bwebb
Nov 20 '18 at 1:18

1

Read other answers to understand what’s wrong. But in general, it’s misguided to talk about what a compiler might do: have you actually looked at what it does, or are you making stuff up? Have you ever checked how well you can predict what a compiler does by writing code, predicting, and checking actual output? You should well get the compiler and look at its output. It’s not magic. Godbolt compiler explorer exists for a reason: so that people don’t have to guess, as such guesses are incorrect more often than not.

– Kuba Ober
Nov 20 '18 at 3:07

add a comment |

-1

Stack

Heap

Data

Shared library

That is how i would answer this question.

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.

Malloc allocates heap memory.

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"

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.

answered Nov 19 '18 at 23:42

Bwebb

3358

Thanks for the down-vote without any comment! It really helps me fix my answer.

– Bwebb
Nov 20 '18 at 1:18

1

Read other answers to understand what’s wrong. But in general, it’s misguided to talk about what a compiler might do: have you actually looked at what it does, or are you making stuff up? Have you ever checked how well you can predict what a compiler does by writing code, predicting, and checking actual output? You should well get the compiler and look at its output. It’s not magic. Godbolt compiler explorer exists for a reason: so that people don’t have to guess, as such guesses are incorrect more often than not.

– Kuba Ober
Nov 20 '18 at 3:07

add a comment |

-1

Stack

Heap

Data

Shared library

That is how i would answer this question.

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.

Malloc allocates heap memory.

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"

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.

answered Nov 19 '18 at 23:42

Bwebb

3358

Stack

Heap

Data

Shared library

That is how i would answer this question.

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.

Malloc allocates heap memory.

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"

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.

answered Nov 19 '18 at 23:42

Bwebb

3358

answered Nov 19 '18 at 23:42

Bwebb

3358

answered Nov 19 '18 at 23:42

Bwebb

3358

answered Nov 19 '18 at 23:42

Bwebb

3358

Thanks for the down-vote without any comment! It really helps me fix my answer.

– Bwebb
Nov 20 '18 at 1:18

1

Read other answers to understand what’s wrong. But in general, it’s misguided to talk about what a compiler might do: have you actually looked at what it does, or are you making stuff up? Have you ever checked how well you can predict what a compiler does by writing code, predicting, and checking actual output? You should well get the compiler and look at its output. It’s not magic. Godbolt compiler explorer exists for a reason: so that people don’t have to guess, as such guesses are incorrect more often than not.

– Kuba Ober
Nov 20 '18 at 3:07

add a comment |

Thanks for the down-vote without any comment! It really helps me fix my answer.

– Bwebb
Nov 20 '18 at 1:18

1

Read other answers to understand what’s wrong. But in general, it’s misguided to talk about what a compiler might do: have you actually looked at what it does, or are you making stuff up? Have you ever checked how well you can predict what a compiler does by writing code, predicting, and checking actual output? You should well get the compiler and look at its output. It’s not magic. Godbolt compiler explorer exists for a reason: so that people don’t have to guess, as such guesses are incorrect more often than not.

– Kuba Ober
Nov 20 '18 at 3:07

Thanks for the down-vote without any comment! It really helps me fix my answer.

– Bwebb
Nov 20 '18 at 1:18

Read other answers to understand what’s wrong. But in general, it’s misguided to talk about what a compiler might do: have you actually looked at what it does, or are you making stuff up? Have you ever checked how well you can predict what a compiler does by writing code, predicting, and checking actual output? You should well get the compiler and look at its output. It’s not magic. Godbolt compiler explorer exists for a reason: so that people don’t have to guess, as such guesses are incorrect more often than not.

– Kuba Ober
Nov 20 '18 at 3:07

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu