I am wondering what happens in the followings situation:

char * test = "hi";
test = "how are you";

Now, the way I understand it, the first line creates a block of memory that contains "h" "i" and "\0". When I have the pointer point to a new string of characters,

if
1) a new block of memory is allocated, what happens to the old block of memory?

if
2) the memory is overwritten, then doesn't this create the possibility that the code unintentionally overwrites memory that shouldn't be touched?

When I really think about it, char *test and char test[] really are interchangeable, right? So the second should apply, I believe.

Just looking for confirmation.
Thanks.

Since those strings are set at compile time, they're stored in memory (i think in a const area, but not sure). When you say 'x = "hello world";', you're just shifting the x pointer to another string which I cant for the life of me remember the name of.

char x[] and char *x are fairly interchangable, yes

Well if I have a user input a string value:

cin >> test;

Will this cause memory to be overwritten (that shouldn't be?). I have to assume that it would overwrite memory in a bad way.

Thanks for your time.

I was gonna post about that too

I forget exactly where static strings are stored in memory, but I think they're flagged as read-only. So you would pass your pointer to char to cin, which would try and write to this illegal memory. Off the top of my head I'm guessing segfault...

Haven't tested this lately to be sure

I am just a hobbyist programmer but there appear to be some basic flaws in your thinking in the above code fragment.

First, you can't assign a value of 'hi' to the pointer 'test' without first assigning it an address of something (the variable 'q' in my example).

Second, the compiler (at least gcc) will allow (but complain), a multicharacter constant in the example below but the output is not what you expect and you are courting crashes with anything more complicated.

#include "stdio.h"

main()
{
char *test, q;
test = &q; /* get q's address */
*test = 'hi'; /* assign q a value using a pointer */
printf("q's value is %c", q); /* simple printf statement to illustrate */
)

Save the above fragment as test.c, run 'gcc test.c' then execute the resulting a.out. Then edit the test.c file to take out the i in 'hi' and see what happens. Hint: Look at the warnings from the compiler as it builds the a.out. Also fiddle with the single quotes I replaced your double quotes with in the assignment statement and see what happens.

nz

EDIT put some whitespace in between the end of my statements and the first comment forward slash character if you cut and past the fragment. Still trying to get used to the darn LQ editor

Hi -

1. Yes, the string constants are allocated at compile time, in a (typically read-only) area called the "TEXT" section.

2. Kroenecker's original post: was perfectly correct. He declared a pointer ("test"), he assigned it to something (the 3-byte constant "hi\0", and then assigned it to something else (the 12-byte constant "how are you\0". All well and good.

3. For whatever it's worth, the following might explain a bit better:
4. You can find out more about the TEXT, DATA, CODE and BSS sections here:
http://www.gnu.org/software/binutils...s_4.html#SEC41

'Hope that helps .. PSM

int a = 0; //global init
char *p1; //global no init
main()
{
int b; //stack
char s[] = "abc";//allocated 4 bytes in stack , writable
char *p2; //stack
char *p3 = "123456"; //123456\0 in constant area ,cann't change .p3 in stack ,usually it contain 4 bytes .
static int c =0; global£¨static£©init
p1 = (char *)malloc(10);
p2 = (char *)malloc(20);
//the above 10 and 20 bytes are allocated in heap,you want to free.
strcpy(p1, "123456");
}

Very much appreciated. That is the first time that I have been able to use gdb. Thanks so much.

I have another question now about std::cin.getline(char*, int n);

If a user inputs a string that is longer than n, it seems that all other getline calls go without putting any value into the buffer be it a new buffer or the old one.

I used gdb to step through, but it wasn't apparent what was going wrong.

Could you give me a hint?

char buffer[10];
std::cin.getline(buffer, 10);
std::cout << buffer << std::endl;
char buffer2[10];
std::cin.getline(buffer2, 10);
std::cout << buffer2 << std::endl;

so is newline creating a problem? And if so, is there a way to "flush" out the newline so that I can get to new user output?

Ive tried using sync() and ignore(), but neither seem to work.

Any ideas?

Again, if the user enters something that is longer than the buffer, is there a way get this code to work?

why do people make their buffers so small?

Oh I'm just curious about how everything works. I wouldn't necessarily write a program with really small buffers.

excellent!
that is the correct answer

reading user input is always a trciky business.

post a complete bit of code so as we can compile and try what you mean.
(I don't use C++ only C, too much typing! )

Well after googling about, I found out about a few helpful stream functions:

stream.fail() and stream.clear()

Basically if getline receives a stream that is too long for the buffer, the fail flag will be set. This flag can be tested by using fail(). So in my case since I'm using cin:

std::cin.getline(buffer, 10);
std:: out << buffer << std::endl;
if( std::cin.fail() )
{
std::cout << "Too much user input... " << std::endl;
std::cin.clear(); // This clears the flag
}
//Now the next getline call will resume where the previous one had
//cut off.
std::cin.getline(second_buffer, 10);
std::cout << second_buffer << std::endl;

In this way you could use cin.fail() in a do while statement to ensure that the user inputs a string that is small enough to fit into your buffer.

Thanks all. I'm sure I will be coming up with more questions in the coming weeks

By the way if anyone can suggest detailed reading about memory allocation at compile time/run time for c/c++, I would appreciate it.

I used to know all about memory allocation
but, er... no, where was I?

it's simple, allocate it. check return value. free it once when finished.
even better, avoid using it at all costs.