0

In C, declaring a char pointer like this

char* p="Hello";

allocates some memory for a string literal Hello\0. When I do this afterwards

p="FTW";

what happens to the memory allocated to Hello\0? Is the address p points to changed?

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
nischayn22
  • 447
  • 3
  • 14

6 Answers6

10

There is no dynamic memory allocation in either statement.

Those strings are stored in your executable, loaded in a (likely read-only) section of memory that will live as long as your process does.

The second assignment only changes what p points to. Nothing else happens.

Mat
  • 202,337
  • 40
  • 393
  • 406
  • So if I go on assigning more values to p I will just be wasting memory (read as memory-leak)? How to use dynamic memory instead? – nischayn22 May 16 '12 at 07:49
  • 1
    You're not leaking anything - those strings are there from the start of your program to its end. If you use dynamic memory allocations (like `malloc`) then you should free it. If you don't, you _must not_ free them. Freeing `p` after the above statements would be a bug (and a crash, very likely). – Mat May 16 '12 at 07:51
  • I meant leaking memory as in memory is wasted because Hello is not used anymore, not free ofc – nischayn22 May 16 '12 at 07:52
  • 1
    I repeat: you are not leaking with those statements. Those strings are part of your process. You would be leaking if you had, yourself, manually, called `malloc` or another dynamic allocation function, and did not free. – Mat May 16 '12 at 07:53
0

The memory remains occupied by "Hello". It is lost (unless you have other references to it).

The address p is pointing to (the value of p) is changed of course.

undur_gongor
  • 15,657
  • 5
  • 63
  • 75
0

In this case, "Hello" is created at compile time and is part of the binary. In most situation "Hello" is stored in read only memory. "FTW" is also part of the binary. Second assignment will only change the pointer.

bkausbk
  • 2,740
  • 1
  • 36
  • 52
0

in addition - "Hello" and "FTW" have static storge duration as Met have pointed out

triclosan
  • 5,578
  • 6
  • 26
  • 50
0

It creates a string constant that cannot be modified and should be used as it is.

If you try doing 

p[0]='m';

It would give segmentation fault since this is not string literal with allocated memory in which you can reassign and read back values.

fkl
  • 5,412
  • 4
  • 28
  • 68
  • 1
    It will not reliably result in a segmentation fault. It is "undefined behavior" and thus might as well "just work" depending on the compiler and its options. – undur_gongor May 16 '12 at 10:20
  • Thanks undur_gongor. Can you please point out a reference? I had gcc infront of my then, and got a seg fault. As much as i remember the same would happen on VS (since i have encountered this before on VS in windows). You mentioned undefined behavior as if it is documented. I would really like to read if that is the case - Thanks – fkl May 17 '12 at 11:36
  • ISO/IEC 9899:1999 lists causes for undefined behavior in its annex J.2, including "The program attempts to modify a string literal". Even more to the point, in 6.4.5 ("String Literals") it says: "If the program attempts to modify such an array, the behavior is undefined." A draft version of the standard is available at http://open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf. – undur_gongor May 18 '12 at 08:20
-1

what if 

p = getbuffer();

getbuffer()
{
   return buf = malloc(buf, size);
}

how can free this memory before allocating new memory to p! imagine that p should use getbuffer() many times.

paria
  • 1