c char指针问题

Question

if we declare char * p="hello"; then since it is written in data section we cannot modify the contents to which p points but we can modify the pointer itself. but i found this example in C Traps and Pitfalls Andrew Koenig AT&T Bell Laboratories Murray Hill, New Jersey 07974

the example is

char *p, *q;
p = "xyz";
q = p;
q[1] = ’Y’;

q would point to memory containing the string xYz. So would p, because p and q point to the same memory.

how is it true if the first statement i mentioned is also true.. similarly i ran the following code

main()
{
char *p="hai friends",*p1;
p1=p;
while(*p!='\0') ++*p++;
printf("%s %s",p,p1);
}

and got the output as ibj!gsjfoet

please explain how in both these cases we are able to modify contents? thanks in advance

Answer 1

Your same example causes a segmentation fault on my system.

You're running into undefined behavior here. .data (note that the string literal might be in .text too) is not necessarily immutable - there is no guarantee that the machine will write protect that memory (via page tables), depending on the operating system and compiler.

Answer 2

Only your OS can guarantee that stuff in the data section is read-only, and even that involves setting segment limits and access flags and using far pointers and such, so it's not always done.

C itself has no such limitation; in a flat memory model (which almost all 32-bit OSes use these days), any bytes in your address space are potentially writable, even stuff in your code section. If you had a pointer to main(), and some knowledge of machine language, and an OS that had stuff set up just right (or rather, failed to prevent it), you could potentially rewrite it to just return 0. Note that this is all black magic of a sort, and is rarely done intentionally, but it's part of what makes C such a powerful language for systems programming.

Answer 3

Even if you can do this and it seems that there are no errors, it's a bad idea. Depending on the program in question, you could end up making it very easy for buffer overflow attacks. A good article explaining this is:

https://www.securecoding.cert.org/confluence/display/seccode/STR30-C.+Do+not+attempt+to+modify+string+literals

Answer 4

main()
{
int i = 0;
char *p= "hai friends", *p1;
p1 = p;
while(*(p + i) != '\0')
    {
        *(p + i);
        i++;
    }
printf("%s %s", p, p1);
return 0;
}

This code will give output: hai friends hai friends

Answer 5

It'll depend on the compiler as to whether that works or not.

x86 is a von Neumann architecture (as opposed to Harvard ), so there's no clear difference between the 'data' and 'program' memory at the basic level (ie the compiler isn't forced into having different types for program vs data memory, and so won't necessarily restrict any variable to one or the other).

So one compiler may allow modification of the string while another does not.

My guess is that a more lenient compiler (eg cl, the MS Visual Studio C++ compiler) would allow this, while a more strict compiler (eg gcc) would not. If your compiler allows it, chances are it's effectively changing your code to something like:

...
char p[] = "hai friends";
char *p1 = p;
...
// (some disassembly required to really see what it's done though)

perhaps with the 'good intention' of allowing new C/C++ coders to code with less restriction / fewer confusing errors. (whether this is a 'Good Thing' is up to much debate and I will keep my opinions mostly out of this post :P)

Out of interest, what compiler did you use?

Answer 6

In olden days, when C as described by K & R in their book "The C Programming Language" was the ahem "standard", what you describe was perfectly OK. In fact, some compilers jumped through hoops to make string literals writable. They'd laboriously copy the strings from the text segment to the data segment on initialisation.

Even now, gcc has a flag to restore this behaviour: -fwritable-strings .

Answer 7

Modifying string literals is a bad idea, but that doesn't mean it might not work.

One really good reason not to: your compiler is allowed to take multiple instances of the same string literal and make them point to the same block of memory. So if "xyz" was defined somewhere else in your code, you could inadvertently break other code that was expecting it to be constant.

Answer 8

Your program also works on my system(windows+cygwin). However the standard says you shouldn't do that though the consequence is not defined.

Following excerpt from the book C: A Reference Manual 5/E, page 33,

You should never attempt to modify the memory that holds the characters of a string constant since be read-only

char p1[] = "Always writable";
char *p2 = "Possibly not writable";
const char p3[] = "Never writable";

p1 line will always work; p2 line ; p3 will always cause a compile-time error.

Answer 9

While modifying a string literal may be possible on your system, that's a quirk of your platform, rather than a guarantee of the language. The actual C language doesn't know anything about .data sections, or .text sections. That's all implementation detail.

On some embedded systems, you won't even have a filesystem to contain a file with a .text section. On some such systems, your string literals will be stored in ROM, and trying to write to the ROM will just crash the device.

If you write code that depends on undefined behavior, and only works on your platform, you can be guaranteed that sooner or later, somebody will think it is a good idea to port it to some new device that doesn't work the way you expected. When that happens, an angry pack of embedded developers will hunt you down and stab you.

Answer 10

p is effectively pointing to read only memory. The result of assigning to the array p points to is probably undefined behavior. Just because the compiler lets you get away with it doesn't mean it's OK.

Take a look at this question from the C-FAQ: comp.lang.c FAQ list · Question 1.32

Q: What is the difference between these initializations?

char a[] = "string literal";
char *p  = "string literal";

My program crashes if I try to assign a new value to p[i].

A: A string literal (the formal term for a double-quoted string in C source) can be used in two slightly different ways:

1. As the initializer for an array of char, as in the declaration of char a[] , it specifies the initial values of the characters in that array (and, if necessary, its size).
2. Anywhere else, it turns into an unnamed, static array of characters, and this unnamed array may be stored in read-only memory, and which therefore cannot necessarily be modified. In an expression context, the array is converted at once to a pointer, as usual (see section 6), so the second declaration initializes p to point to the unnamed array's first element.

Some compilers have a switch controlling whether string literals are writable or not (for compiling old code), and some may have options to cause string literals to be formally treated as arrays of const char (for better error catching).

Answer 11

I think you are making a big confusion on a very important general concept to understand when using C, C++ or other low-level languages. In a low-level language there is an implicit assumption than the programmer knows what s/he is doing and makes no programming error .

This assumption allows the implementers of the language to just ignore what should happen if the programmer is violating the rules. The end effect is that in C or C++ there is no "runtime error" guarantee... if you do something bad simply it's NOT DEFINED ("undefined behaviour" is the legalese term) what is going to happen. May be a crash (if you're very lucky), or may be just apparently nothing (unfortunately most of the times... with may be a crash in a perfectly valid place one million executed instructions later).

For example if you access outside of an array MAY BE you will get a crash, may be not, may even be a daemon will come out of your nose (this is the "nasal daemon" you may find on the internet). It's just not something that who wrote the compiler took care thinking to.

Just never do that (if you care about writing decent programs).

An additional burden on who uses low level languages is that you must learn all the rules very well and you must never violate them. If you violate a rule you cannot expect a "runtime error angel" to help you... only "undefined behaviour daemons" are present down there.