Unhandled exception - Access Violation!

[Naresh Agarwal]

Consider the following two pices of code

Code 1:

----
#include <iostream.h>

void main()
{
char *a="hello";
*a='b'; // throws exception - "Access Violation" at runtime
cout<<a<<endl;
}
-----

Code 2:

----
#include <iostream.h>

void main()
{
char a[6]="hello";
*a='b';
cout<<a<<endl;
}
-----

When we run Code 1, then we get unhandled expcetion for Access Violation at
second statement. However Code displays "bello" and run properly. Why?

thanks,
regards,
Naresh Agarwal

[Torsten Müller]

"Naresh Agarwal" <naga...@firstrain.com> schrieb:

> char *a="hello";

> char a[6]="hello";

This first line is a string constant, the second one is an array of
six characters initialized by a string constant. A significant
difference can be the location. The compiler can locate the string
constant in the code segment or in a read only data segment, while the
array is located on the stack. So modifying a string constant will
cause an access violation, and this is good.

T.M.

[Naresh Agarwal]

>The compiler can locate the string
> constant in the code segment or in a read only data segment, while the
> array is located on the stack.

why compiler will locate the string constant in code segment. Do u mean to
say that
the string constant would get memory from heap?

Also if "hello" is const char * (as it is a constant string)

Then char *a="hello" should be invalid as it involves conversion of const
char * to char *, which
is not valid.

regards,
Naresh Agarwal

"Torsten Müller" <Homun...@gmx.net> wrote in message
news:u3cpmn...@gmx.net...

[Torsten Müller]

"Naresh Agarwal" <naga...@firstrain.com> schrieb:

> > The compiler can locate the string constant in the code segment or
> > in a read only data segment, while the array is located on the
> > stack.
>
> why compiler will locate the string constant in code segment. Do u
> mean to say that the string constant would get memory from heap?

No, it does not! It _can_ be compiled into the code. And the code is
surely read only. The reason for putting constants into code is: speed.

> Also if "hello" is const char * (as it is a constant string)
>
> Then char *a="hello" should be invalid as it involves conversion of
> const char * to char *, which is not valid.

Look, it is _never_ possible to modify a string constant. If you
initialize a non-const char* by a string literal ...

char* ptr="hello";

... the string literal remains a constant in all of its properties.
This does not depend on the kind of the pointer. You should really
declare this pointer const.

If you want to modify a string, you should use an array of characters.
An array of characters is not a string constant (except it's a const
array). A construction like

char a[10]="abcdefghi";

is indeed an array on the stack. And the value of the literal will be
_copied_ into it regardless where this value is located. This is also
the reason why

char b[10]="abc";

has also a size of 10 (!) characters, but the actual length will be 3.

T.M.

[Ron Ruble]

"Naresh Agarwal" <naga...@firstrain.com> wrote in message
news:OObynTslCHA.1492@tkmsftngp02...
<snip>

> why compiler will locate the string constant
> in code segment. Do u mean to say that
> the string constant would get memory from heap?

A literal string _may_ (not will) be located in
read only memory. This behavior is specifically
permitted by the C and C++ standards.

The VC compiler places string literals in read-
only memory by default. Since the code segment
is read-only, the compiler places these literals
in the code segment.

Not heap, not stack. _Code segment_.

For more details, see the MSDN documentation.

> Also if "hello" is const char * (as it is a constant string)

Wrongo. "hello" is _not_ a const char *;
"hello" is a string literal, which is constant (not
const) and is a string of characters (not a character
string).

"const" is a C++ language feature, a data qualifier.
"Constant" is an attribute of the underlying
implementation.

char *a="hello";

does not apply the const qualifier, although the
string literal is constant (not const).

> Then char *a="hello" should be invalid
> as it involves conversion of const char *
> to char *, which is not valid.

Wrongo, because a is not const, it is constant.

You would only get the warning if you declared
a const, not by its being a constant. It is constant,
but you didn't tell the compiler it is const, so it
isn't.

In C++, the following things are all different:

literal strings
compile-time constants
const variables

You're mixing them all up, and this is confusing
you.

See the following resources:
http://www.parashift.com/c++-faq-lite/const-correctness.html
http://www.tietovayla.fi/borland/cplus/faq/faqcpp2.htm#const
http://www.cplusplus.com/doc/tutorial/tut1-2.html
http://cpptips.hyperformix.com/Const.html
http://bit.csc.lsu.edu/tutorial/ten-commandments/c-faq/c-17.html#17-20

And some general FAQs

Welcome to comp.lang.c++
http://www.slack.net/~shiva/welcome.txt

Off-topic posts
http://www.slack.net/~shiva/offtopic.txt

The comp.lang.c FAQ
http://www.eskimo.com/~scs/C-faq/top.html

The comp.lang.c++ FAQ Lite
http://www.parashift.com/c++-faq-lite/

Alternate C FAQ - gives some tips for platform-
specific problems
http://bit.csc.lsu.edu/tutorial/ten-commandments/c-faq/c-faq-toc.html

and one from my web site: 'How to get help via usenet news'
http://home.att.net/~raffles1/how_to_get_help.htm

[Carl Daniel [MVP]]

"Naresh Agarwal" <naga...@firstrain.com> wrote in message
news:OObynTslCHA.1492@tkmsftngp02...

> Also if "hello" is const char * (as it is a constant string)
>
> Then char *a="hello" should be invalid as it involves conversion of const
> char * to char *, which
> is not valid.

In a completely sensible world, you would be correct. There is, however, a
special allowance in the C++ standard for an implicit conversion from const
char* to char* that makes this code legal. (See section 4.2/2 of the C++
spec).

That allowance is also in ANSI C, and was added in order to not break the
millions of lines of existing C code that predate the introduction of the
'const' concept to C (and hence, to C++).

-cd