Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > No compile-time error on modifying string literals

Reply
Thread Tools

No compile-time error on modifying string literals

 
 
Victor Bazarov
Guest
Posts: n/a
 
      02-14-2005
Ney André de Mello Zunino wrote:
> The following is a summary of what I have understood from reading
> Stroustrup's TCPL 3rd Edition's discourse on "string literals" (5.2.2).
>
> String literals are of type const char[n], where n is the length of the
> literal plus one. However, for compatibility reasons, assignment of such
> a literal to a non-const char* is allowed, e.g.:
>
> char* name = "Ney Zunino";
>
> In spite of that assignment being allowed, it is not permitted to use
> that pointer to modify the string literal. Next, Stroustrup adds that
> this kind of error cannot generally be caught until runtime. As a matter
> of fact, that's precisely what I have experienced with the following
> test program:
>
> int main()
> {
> char* s = "Ney André de Mello Zunino";
> s[2] = 'i';
> }
>
> Both Microsoft Visual C++ 2003 and g++ 3.3.3 compiled it quietly and
> both executables caused protection faults at runtime. Fine, it all went
> just like Stroustrup had said, but what I don't understand is why. Why
> is it so hard for a compiler to catch such violation? Isn't it clear
> that the address assigned to 's' was that of a statically-allocated
> literal?


Why bother catching it if the Standard doesn't require catching it? The
fact that you're trying to modify a literal becomes much less clear if
you pass the pointer into another function which will modify the contents
and even less clear if that function is in another translation unit. So,
instead of requiring the implementations to watch out for those, the C++
Standard simply says that an attempt to modify leads to undefined
behavoiur. It's up to you as a programmer to prevent it. There are tools
that go the extra mile to try to fish out those mistakes. Are they good?
Those who use them can probably tell. I don't use them. I simply don't
write code like in your example.

V
 
Reply With Quote
 
 
 
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      02-14-2005
Ney André de Mello Zunino wrote:
>
>
> Both Microsoft Visual C++ 2003 and g++ 3.3.3 compiled it quietly and
> both executables caused protection faults at runtime. Fine, it all went
> just like Stroustrup had said, but what I don't understand is why. Why
> is it so hard for a compiler to catch such violation? Isn't it clear
> that the address assigned to 's' was that of a statically-allocated literal?


In this case: yes.
In the general case: no

void foo( char* check )
{
check[2] = 'n';
}

Now, does the above function attempt to modify a string literal?
Nobody knows until runtime, when the caller of that function
passes an address.

--
Karl Heinz Buchegger
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=
Guest
Posts: n/a
 
      02-14-2005
Hello.

The following is a summary of what I have understood from reading
Stroustrup's TCPL 3rd Edition's discourse on "string literals" (5.2.2).

String literals are of type const char[n], where n is the length of the
literal plus one. However, for compatibility reasons, assignment of such
a literal to a non-const char* is allowed, e.g.:

char* name = "Ney Zunino";

In spite of that assignment being allowed, it is not permitted to use
that pointer to modify the string literal. Next, Stroustrup adds that
this kind of error cannot generally be caught until runtime. As a matter
of fact, that's precisely what I have experienced with the following
test program:

int main()
{
char* s = "Ney André de Mello Zunino";
s[2] = 'i';
}

Both Microsoft Visual C++ 2003 and g++ 3.3.3 compiled it quietly and
both executables caused protection faults at runtime. Fine, it all went
just like Stroustrup had said, but what I don't understand is why. Why
is it so hard for a compiler to catch such violation? Isn't it clear
that the address assigned to 's' was that of a statically-allocated literal?

Thank you for your comments,

--
Ney André de Mello Zunino
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      02-14-2005

Karl Heinz Buchegger wrote:
> Ney André de Mello Zunino wrote:
> >
> >
> > Both Microsoft Visual C++ 2003 and g++ 3.3.3 compiled it quietly

and
> > both executables caused protection faults at runtime. Fine, it all

went
> > just like Stroustrup had said, but what I don't understand is why.

Why
> > is it so hard for a compiler to catch such violation? Isn't it

clear
> > that the address assigned to 's' was that of a statically-allocated

literal?
>
> In this case: yes.
> In the general case: no
>
> void foo( char* check )
> {
> check[2] = 'n';
> }
>
> Now, does the above function attempt to modify a string literal?
> Nobody knows until runtime, when the caller of that function
> passes an address.


To make the point more obvious, that same function could look like
this:

void foo(char check[])
{
check[2] = 'n';
}

and it wouldn't make a bit of difference in the end.

On the other hand, if your literals are declaired const the compiler
will generate a warning if you pass them as non-const parameters:

const char *x = "ABCD";
foo(x);

will generate a warning complaining about the discarding of const in
the call to foo...might even error in C++, not sure. The const keyword
will protect you in many ways.

 
Reply With Quote
 
=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=
Guest
Posts: n/a
 
      02-14-2005
Karl Heinz Buchegger wrote:

[...]

> void foo( char* check )
> {
> check[2] = 'n';
> }
>
> Now, does the above function attempt to modify a string literal?
> Nobody knows until runtime, when the caller of that function
> passes an address.


Of course you and Victor are right. Thanks for clarifying it.

--
Ney André de Mello Zunino
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Java: byte literals and short literals John Goche Java 8 01-17-2006 11:12 PM
Unicode String Literals didster@gmail.com Java 4 11-21-2005 11:43 AM
Generic class literals - e.g,, Class<Map<String, Integer>>.class Purush Java 4 04-13-2005 08:40 PM
character literals and string Pete Elmgreen Java 3 11-24-2004 04:42 PM
String literals in Java Harri Pesonen Java 59 06-02-2004 08:00 PM



Advertisments