String Pointer Causing Access Violation

[Adron]

You're still incorrect in either case. And yes, I am aware of what a pointer is. When you said point to I took that to mean, the program itself refers to it (*buf) as 1 byte, which is not the case.

You still don't understand do you?
The point is it allocates memory for that null terminated string, it doesn't matter if it's allocated on the stack heap/free store or statically when the program starts, it's still allocated.

Arta originally said no allocation occurs, and my point stands that this is not true. If you don't understand the posts don't bother replying as you simply embarrass yourself by making dumb remarks.

I'll take this time to point out that there is a possibility of no allocation occurring for the string. There will always be an allocation for the pointer (4 bytes in the intel 32-bit architecture), but the empty null terminated string may not necessarily cause any allocation at all to happen. Hint: Look at compiler optimizations for merging string constants.

Additionally for the string, no allocation will happen at run-time, and there will also not be an allocation done on stack, both of which you have incorrectly claimed before.



Edit: Throwing in more examples of how virtually every post by OnlyMeat is incorrect...

Seems clear to me you are saying the code snippet above doesn't allocate any memory. This is incorrect, if you don't believe me run the code in my reply, you will find the size of the variable buf == 1 (the null terminator). This is clearly allocating 1 byte on the stack giving you a valid zero length string:-

Code Select Expand


char* buf = "";
char* buf2="hello";
cout << sizeof(*buf) << buf2 << endl;


#1: It's not allocating a byte on the stack
#2: It may not be allocating anything at all
#3: You're not testing for anything being allocated; example:

Code Select Expand


char* buf = 0;
char* buf2="hello";
cout << sizeof(*buf) << buf2 << endl;


Tell me how assigning null to a pointer would be allocating a byte for it? Yet according to you, sizeof says it does?

Say what you like but the point is buf points to 1 byte of memory. You just agreed with that thanks .

Memory is committed (in win32) in 4096 byte blocks, also known as pages. Your pointer will point to somewhere in your address space. There most likely won't be just 1 byte available at the location buf points to, much like when you allocate 5 bytes there won't most likely be just 5 bytes where your pointer points to. Maybe what you wanted to say was "buf points to 1 byte of memory allocated for you to use as you like"? Unfortunately that'd be incorrect as well...

It has a static lifetime, however it must still be allocated and loaded into memory at runtime. Which proves the point that the variable buf will point to 1 byte of data. It doesn't matter if it's on the stack or allocated when the program starts statically it will be allocated in memory.

There will be memory for the '\0', that's all you can say. That memory may have been allocated for the byte, or it may have been allocated for something else and reused for the '\0'. The memory may be allocated a load-time, or it may have been allocated much earlier. An example would be writing code for a BIOS chip, in which case you might say the memory was allocated when the EEPROM was written. The point is that the declaration char *buf = ""; not necessarily causes an allocation, and particularly doesn't give you  memory that you can do anything other than read a '\0' from.

[Banana fanna fo fanna]

Aren't all string constants allocated and loaded into memory at startup?

[Adron]

Aren't all string constants allocated and loaded into memory at startup?

Not necessarily. They can be memory mapped from an exe file, meaning they load when you access them. Some string constants may have been merged with other string constants, meaning they're not allocated any separate space. In some applications constants aren't loaded at startup, they just exist (example: BIOS ROM).