Where does compiler allocate memory for Char x[] = "abc" ?

Where does compiler allocate memory for "abc" that x points to?
I think it's on heap. Am I right?
(assume Char x[] = "abc" is defined at global scope)

Added: Please note that I mean the "abc" x is pointing to. It's different from the original "abc" literal. It's initialized by the original "abc" literal.
Added: After discussion we believe it's compiler depended. But in most cases it's on data segment. Any comments?

Where "x" is allocated depends on where the declaration is at. It can be on the stack if that line of code is in a function somewhere.

If you mean where is "abc" allocated at, that would be in the data section of the executable.

Thanks. x is defined at global scope. I think it's on heap, right?

No, that would also go in the data section.

Quote:

---

Originally Posted by bithub

No, that would also go in the data section.

---

If it's

Code:

---

Char * x = "abc";

---

I think you are right.

But for

Code:

---

Char x[] = "abc";

---

I think compiler allocate 4 bytes memory on heap and copy "abc\0" to the space.
Am I right?

The standard doesn't specify where exactly the literal exists in memory, of course, but yes, it generally ends up in the 'data' section (or some other read-only area).

Quote:

---

Originally Posted by meili100

If it's

Code:

---

Char * x = "abc";

---

I think you are right.

But for

Code:

---

Char x[] = "abc";

---

I think compiler allocate 4 bytes memory on heap and copy "abc\0" to the space.
Am I right?

---

Again, it's free to put it wherever is pleases, but for all implementations I can think of the answer would be "no". For one thing, it isn't practical (or even possible) to mark an area of the heap as "read-only", so bithub's response(s) are most likely going to be in-line with how your particular compiler implements it.

Hang on a minute. Is there any normally declared array that ends up on the heap? Just because you're using an initializer doesn't make this act like a call to malloc. (EDIT: Obviously this is all system-dependent etc etc etc. But using the general idea of "stack" and "heap" and "data segment" etc.)

I think he's referring to the initializer itself.

If the array is a local variable, then it exists on the stack. When the function is entered, space for the array is allocated on the stack, and then the string literal is copied into the array.

The string literal itself may or may not exist in the data segment. For longer strings, it almost certainly does. For very short strings, the compiler may choose to inline the copy (embed the string literal into the code as immediate data).

The heap has nothing to do with any of this.

Quote:

---

Originally Posted by Sebastiani

For one thing, it isn't practical (or even possible) to mark an area of the heap as "read-only".

---

I think it's not "read only". In fact you can modify it:

Code:

---

Char x [] = "abc";
x[0] = 'z';

---

The memory that x points to is NOT a literal.

Quote:

---

Originally Posted by meili100

I think it's not "read only". In fact you can modify it:

Code:

---

Char x [] = "abc";
x[0] = 'z';

---

The memory that x points to is NOT a literal.

---

I was referring to the literal "abc" - not the array that is initialized by it. Point is, whether it exists in the data section, or as brewbuck pointed out, directly in the code, it's generally going to be in a read-only section (though I'm not even sure if the standard mandates that).

Since x is global, it too would be in the data segment, albeit in read-write data area.

Quote:

---

Originally Posted by Sebastiani

For one thing, it isn't practical (or even possible) to mark an area of the heap as "read-only"

---

At least using system calls you can make any (virtual) memory region read-only.
Memory Protection Constants (Windows)