tags:

views:

254

answers:

7

In c/c++ some people use c-styled strings like:

char *str = "This is a c-styled string";

My question is is this safe? The way I see it is they created a char pointer that points to the first letter of a const array of chars, but can't some other thing eg another variable overwrite a portion of the char array in the memory? Thus causing str to be logically invalid?

+1  A: 

It is unsafe. But so are any other things in C/C++. You can easily overwrite the portion of the memory used by some other object.

Naveen
+6  A: 

These days string constants are placed in read-only sections of your binary. If you attempt to write to an address in a read-only section the CPU's memory management unit will cause a fault and your application will get an access violation or segmentation fault or some other operating system dependent behavior.

Also, compilers warn if you declare the type of the string constant to be non const.

karunski
Stored in read-only sections of memory... now everything makes sense... thx~
There's a rather large world of non-Intel-y, and even non-MMU, environments out there where this won't be the case. Nothing in the C or C++ standards dictates this behavior since it's undefined (*very* different from implementation-defined). You may want to make it clear that this answer is common practice for architectures that support it, but is in no way mandated.
paxdiablo
A: 

Do not actually do this:

int *foo = 0x1234;
byte[] bytes = (byte[]) foo;
bytes[0] = 0x56;

printf("%d\n", *foo);

That said, any pointer is dangerous if misused.

Matthew Scharley
+6  A: 

but can't some other thing eg another variable overwrite a portion of the char array in the memory?

They must not do that. The reason is that your C-string literal is a constant and correctly it should be declared as one:

char const* str = "This is a c-styled string";

Your (non-const) code is only allowed out of compatibility to legacy C code. Attempts to modify the data result in undefined behaviour.

Konrad Rudolph
It should be const char str[] that is the real type. Why to lose the compile-time size information?
fnieto
@fnieto: Good comment. Will this be optimized to point to a literal, though, or will it always be copied (despite the `const` qualifier)? I’d hate for all my literal strings to be copied.
Konrad Rudolph
@fnieto: The semantics are different though. As Konrad says, if it'd been declared as an array, you'd get a local copy of the statically allocated string. With a char pointer, you just point to the original statically allocated string.
jalf
+3  A: 

Things are as safe as you make them. You can just as easily overwrite integers on the stack as you can strings. In fact, what you have in your question is safer (in some systems) since it may well be placed in a read-only memory section.

People shouldn't be using C if they don't know what they're doing. Just like they shouldn't be using a chainsaw without proper training. The whole raison d'etre of C was a systems programming language. It gives you the full power to do what you want. And with power comes responsibility.

paxdiablo
A: 

Depends on what you mean by "safe".

They are not less inherently safe than any other use of pointers in C/C++. Pointers require you to be very careful with memory in general.

acrosman
A: 

They are as safe as your programming practices. As long as you know how to work with them properly, they are perfectly safe. For those whose programming style makes one think of an elephant in a china shop, such strings might not be safe. But then the same thing can be said about the entire C/C++ languages.

Your original one-line declaration example already suffers from unsafe style problems. In both C and C++ string literals are non-modifyable lvalues. It is not a good idea to create [long-lived] non-const pointers pointing into such literals. Normally, it should look as follows

const char *str = "This is a c-styled string";

Note the extra 'const'.

(This particular rule cannot be always followed in C, but normally it is only necessary to violate it in some well-controlled localized idiomatic code.)

AndreyT