By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,482 Members | 1,611 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,482 IT Pros & Developers. It's quick & easy.

Difference between char* and char array

P: n/a
Can anyone tell me :

1.
void main()
{

char temp[] = "Hello";

temp[0]='K';

}
2.

void main()
{

char* temp = "Hello";

temp[0]='K';

}

1st one gives an access violation whereas second one is done
successfully. I want to know why the fist one gives a runtime-error? I
want to know what happens internally? How the compiler interprets this
two snippets?

Jul 23 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
am*********@gmail.com wrote:
Can anyone tell me :

1.
void main()
{

char temp[] = "Hello";

temp[0]='K';

}
2.

void main()
{

char* temp = "Hello";

temp[0]='K';

}

1st one gives an access violation whereas second one is done
successfully.
Actually, both are incorrect. main must always return int.
I want to know why the fist one gives a runtime-error?
The first shouldn't produce an error, but the second may.
I want to know what happens internally? How the compiler interprets this
two snippets?


In the first one, an array of 6 char is created locally in the function and
the contents of the string literal "Hello" is copied into it. Afterwards,
you overwrite the first element of that array.
In the second snippet, a pointer to the first character literal itself is
created. This pointer should better be a const char*, because string
literals are constant and must not be modified. When you try to write to
temp[0], you access read-only memory.

Jul 23 '05 #2

P: n/a
Actually, both are incorrect. main must always return int.
I know when you return something (integer) from main it goes back to the progammers environment. I also know you are right main always should return int. But, why is it like that? whats the use of it?


Jul 23 '05 #3

P: n/a
<am*********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Actually, both are incorrect. main must always return int.
I know when you return something (integer) from main it
goes back to the progammers environment. I also know you
are right main always should return int. But, why is it
like that? whats the use of it?


Because the 'integer from main goes back to the programs
environment.' The environment may do whatever it likes, including
nothing. So for the programmers point of view, it's not really of
interest, what will be done with the return value. It's only important
that we must play by the rules .. ie. the Standard.

If you do not, imagine an environment where return values are passed
on the stack. So the caller of your program needs to remove the return
value, no matter if it needs it or not. If you return void, you never
put something on the stack .. but the environment does not know that,
right? So instead of wiping your (should-be-but-is-not-existant) return
value, it will remove other information .. and you can expect this to
end in a not user-friendly way.

regards
--
jb

(reply address in rot13, unscramble first)
Jul 23 '05 #4

P: n/a
>If you do not, imagine an environment where return values are >passed
on the stack. So the caller of your program needs to remove the >return value


Why the caller of my program will be attempting to remove the return
value if i declare my main()
functions as " void main() { }". As you can see I have already
mentioned that main() is not going to return any value, so tha caller
should not make any attempt to remove return value.

Thanks in advance..

Regards
Ambar

Jul 23 '05 #5

P: n/a
<am*********@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
If you do not, imagine an environment where return values are >passed
on the stack. So the caller of your program needs to remove the
>return value


Why the caller of my program will be attempting to remove the return
value if i declare my main()
functions as " void main() { }". As you can see I have already
mentioned that main() is not going to return any value, so tha caller
should not make any attempt to remove return value.

You told the compiler. Not the environment. That is a difference.

regards
--
jb

(reply address in rot13, unscramble first)
Jul 23 '05 #6

P: n/a
am*********@gmail.com wrote:
If you do not, imagine an environment where return values are >passed
on the stack. So the caller of your program needs to remove the >return
value
Why the caller of my program will be attempting to remove the return
value if i declare my main() functions as " void main() { }".


Because the C++ standard says that a program always must return int. The
caller of your program might count on that and just expect your program to
do it.
As you can see I have already mentioned that main() is not going to return
any value, so tha caller should not make any attempt to remove return
value.


The caller doesn't necessarily know that you didn't play by the rules.

Jul 23 '05 #7

P: n/a
Rolf Magnus wrote:
am*********@gmail.com wrote:
If you do not, imagine an environment where return values are >passed
on the stack. So the caller of your program needs to remove the >return
value


Why the caller of my program will be attempting to remove the return
value if i declare my main() functions as " void main() { }".


Because the C++ standard says that a program always must return int. The
caller of your program might count on that and just expect your program to
do it.
As you can see I have already mentioned that main() is not going to return
any value, so tha caller should not make any attempt to remove return
value.


The caller doesn't necessarily know that you didn't play by the rules.


Actually, the C++ standard states that main must be declared to return
an int, it does not require that the program's main routine actually do
so, that is, to return an int or to return anything at all. It is
perfectly legal for a C++ program to "fall off" the end of the main
routine without ever executing a return statement.

In the case that a C++ program reaches the end of main, the program
terminates and the value 0 is returned to the environment. And as a
practical matter, it's likely that most implementations would always
have the program return 0 to the environment in this situation, no
matter the declaration of main.

Even if the 0 were not supplied, the return value of a program or a
function call on most systems is placed in a register. So there is
little danger of the caller "removing" a value that is not present, and
fouling things up. Rather whatever value is found in the register on
program exit is taken to be the result returned by the program. Whether
the program itself determined that value, or the C++ compiler did so on
the program's behalf, is not known by, nor should it make any
difference to, the caller.

Greg

Jul 23 '05 #8

P: n/a
Me
am*********@gmail.com wrote:
Can anyone tell me :

1.
char temp[] = "Hello";
temp[0]='K';
In this example,

char temp[] = "Hello";

is just syntax sugar for:

char temp[6] = { 'H', 'e', 'l', 'l', 'o', '\0' };
2.

char* temp = "Hello";
temp[0]='K';
In this example, "Hello" is a const char[6] (i.e. a 6 element array of
const chars). Unfortunately, due to backwards compatibility with legacy
C code, the current C++ standard allows arrays of const char to decay
to char * during standard conversions as a special case (otherwise you
would be required to do const char *temp = "Hello"). Just because you
can implicitly convert to it as a special case doesn't mean assigning
to it becomes legal all of a sudden. It's the same reason the following
is illegal:

const char c = 'H';
char *temp = const_cast<char*>(&c);
*temp = 'K';
1st one gives an access violation whereas second one is done
successfully. I want to know why the fist one gives a runtime-error? I
want to know what happens internally? How the compiler interprets this
two snippets?


I think you got this backwards. The first example is legal whereas the
second one is undefined.

Jul 23 '05 #9

P: n/a
"Greg" <gr****@pacbell.net> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
Even if the 0 were not supplied, the return value of a program or a
function call on most systems is placed in a register. So there is
little danger of the caller "removing" a value that is not present,
and


'most' depends on what you work with. To be honest, I have no ideas
if such machines exist, but why should this make me not play by the
rules. You seem to be discouraging people from using 'int main', because
'void main' is not such a big deal to you. Why not look at it the other
way round: a) you play by the rules, b) you do not have to watch out for
it when coding for a new system, and c) you even have to type less.

The bottom line is: even though 'void main' might work for you and
your friends, 'int main' will save you trouble in the end; there's no
reason not to go for 'int main'.

regards
--
jb

(reply address in rot13, unscramble first)
Jul 23 '05 #10

P: n/a
Hi,
I am not discouraging

Jul 23 '05 #11

P: n/a
Hi,

I am not discouraging people from using 'int main'. If using 'int main'
is a standard then there must be some reason to follow that standard. I
am just trying to find out that reason. So far what you said and what
Greg said are not in sync at all. Greg stated
"In the case that a C++ program reaches the end of main, the program
terminates and the value 0 is returned to the environment"
and "Even if the 0 were not supplied, the return value of a program or
a function call on most systems is placed in a register. "

Now you said ". If you return void, you never put something on the
stack .. but the environment does not know that, " .
I am totally confused and cant decide which one I should accept. May be
only Stroustrup can tell us what exactly happens . Or can you guys can
synchoronize your statements so that I can accept that as final. I
really need to know this.

Thanking you in advance.

Ambar

Jul 23 '05 #12

P: n/a
am*********@gmail.com wrote:

Now you said ". If you return void, you never put something on the
stack .. but the environment does not know that, " .
I am totally confused and cant decide which one I should accept. May be
only Stroustrup can tell us what exactly happens .


No one can tell you what exactly will happen, because here you are at an
interface. The interface connects your program with the outside
world.
Well the outside world is fixed and it might or it might not expect
the program to return an int in some way. But neither you, nor your program
can't change that. If that outside world expects your program to return
an int in some way, and your program doesn't play by the rules, then
anything imaginable might happen.
Before you ask: Yes, the outside world has every right to expect your
program to return an int. The rules of C++ dictate that the program *must*
return an int, so the outside world can rely on that fact.

Even if your development environment lets you get away with void main(), it doesn't
mean it is correct to do so.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #13

P: n/a
Greg wrote:
Rolf Magnus wrote:
am*********@gmail.com wrote:
>>If you do not, imagine an environment where return values are >passed
>>on the stack. So the caller of your program needs to remove the >return
>>value
>
> Why the caller of my program will be attempting to remove the return
> value if i declare my main() functions as " void main() { }".
Because the C++ standard says that a program always must return int. The
caller of your program might count on that and just expect your program
to do it.
> As you can see I have already mentioned that main() is not going to
> return any value, so tha caller should not make any attempt to remove
> return value.


The caller doesn't necessarily know that you didn't play by the rules.


Actually, the C++ standard states that main must be declared to return
an int, it does not require that the program's main routine actually do
so, that is, to return an int or to return anything at all. It is
perfectly legal for a C++ program to "fall off" the end of the main
routine without ever executing a return statement. In the case that a C++
program reaches the end of main, the program terminates and the value 0 is
returned to the environment


I'd rather describe it like this: If you declare main() to return int, it
does return int. The C++ standard just contains an exception for main()
that you don't need to write down the return statement. If you don't, 0
will implicitly be returned. This is guaranteed.
. And as a
practical matter, it's likely that most implementations would always
have the program return 0 to the environment in this situation, no
matter the declaration of main.
Words like "likely" and "most" already indicate that it's not necessarily
the case for all implementations. So what's the advantage of doing
something that is likely to work instead of something that is formally
correct and guaranteed to work?
Even if the 0 were not supplied, the return value of a program or a
function call on most systems is placed in a register. So there is
little danger of the caller "removing" a value that is not present, and
fouling things up.


Well, it depends on the environment. If it does do what you describe, there
is no danger at all. If it doesn't, there is great danger. You cannot
average the danger.

Jul 23 '05 #14

P: n/a
Me wrote:
Unfortunately, due to backwards compatibility with legacy C code, the
current C++ standard allows arrays of const char to decay to char * during
standard conversions as a special case (otherwise you would be required to
do const char *temp = "Hello").
This is only true for string literals.

char * c = "Hello"; // ok, even though the literal is of type const char[6].
const char[] d = "Hello";
char* e = d; // error, because of ignoring const.

Just because you can implicitly convert to it as a special case doesn't
mean assigning to it becomes legal all of a sudden.


The conversion is legal. Using the pointer to write to the string literal is
not.

Jul 23 '05 #15

P: n/a
Jakob Bieling wrote:
"Greg" <gr****@pacbell.net> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
Even if the 0 were not supplied, the return value of a program or a
function call on most systems is placed in a register. So there is
little danger of the caller "removing" a value that is not present,
and


'most' depends on what you work with. To be honest, I have no ideas
if such machines exist, but why should this make me not play by the
rules. You seem to be discouraging people from using 'int main', because
'void main' is not such a big deal to you. Why not look at it the other
way round: a) you play by the rules, b) you do not have to watch out for
it when coding for a new system, and c) you even have to type less.

The bottom line is: even though 'void main' might work for you and
your friends, 'int main' will save you trouble in the end; there's no
reason not to go for 'int main'.

regards
--
jb


By applying the C++ standard's own illogical rules governing the
function main, it is easy enough to conclude that void main() is in
fact allowed by the standard.

As I pointed out earlier, the standard's rules concerning main's
declaration are completely at odds with its rules for main's
implementation. On the one hand, the C++ standard requires that main's
definition specify int as its return type, while on the other hand, the
standard specifically exempts main's function body from adhering to
this declaration. The Standard allows main to be coded to return no
value at all. For any other function, such a disagreement could not be
legally compiled. But in the eyes of the standard, main is no ordinary
C++ function.

The C++ standard therefore takes the illogical position that main must
have an int-returning declaration which can be legally paired with a
void main() implementation. Clearly this state of affairs would be
better resolved in either direction. And by applying the "as-if" rule
in this situation, a compiler should be allowed, from the user's
perspective, to do just that: accept a void main() declaration to match
main's legal implementation. Because such a declaration behaves exactly
"as-if" the standard's baffling requirements were still being
religiously followed.

For the compiled application, whether main is declared to return an int
or declared to return nothing will make no difference at all. All the
compiler has to do is to continue to supply an implicit "return 0"
statement on the last line of main, regardless of main's declaration.
After all having a void function return a value is actually legal in
C++, and certainly makes more sense than than a rule that exempts a
function declared to return an int from having to return any specified
value at all. In other words a void main() implement is simply
"Standardese sugar" to please a body of C++ users, without having to
depart from the requirements of the standard in any meaningful way at
all.

Greg

Jul 23 '05 #16

P: n/a
"Greg" <gr****@pacbell.net> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
implementation. On the one hand, the C++ standard requires that main's
definition specify int as its return type, while on the other hand,
the
standard specifically exempts main's function body from adhering to
this declaration. The Standard allows main to be coded to return no
value at all. For any other function, such a disagreement could not be
It allows you to return (ie. code it to return) no value. But it
is stated that an implicit 'return 0' is issued if you omit it (see
3.6.1/5).
For the compiled application, whether main is declared to return an
int
or declared to return nothing will make no difference at all. All the
compiler has to do is to continue to supply an implicit "return 0"
statement on the last line of main, regardless of main's declaration.


It probably could, but as long as it is not guaranteed, do not rely
on it and play by the rules.

In additon, if I may get back to your argument about the logic of
rules: having the compiler issue a 'return 0' for a function that is
declared to return 'void' is far more illogical than requesting the
compiler to issue 'return 0' for main, if there is no return statement
... despite the fact that it is just as legal. Keeping that in mind,
there is no gain at all. You do not get rid of exceptions for main.

That said, why insist on 'void main'? If you accept the exception of
possibly having 'return 0' issued automatically, the logic is flawless
and the program is well defined! If you do not, you have to specify
other exceptions to be able to have a function defined to return 'void',
but actually returning an error code .. apart from that extra keystroke
;)

regards
--
jb

(reply address in rot13, unscramble first)
Jul 23 '05 #17

P: n/a
<am*********@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Now you said ". If you return void, you never put something on the
stack .. but the environment does not know that, " .


Right, it was an example to illustrate that using 'void main' could
have severe consequences on systems that implement returning a value by
using the stack. I have not seen any such systems, but I have not seen
$1 million either .. they might exist, and actually I am pretty sure
they exist.

Greg is referring to a special (though widely used in the personal
computing area) set of systems .. systems that use registers to return
the return value of a function. But C++ is more than just a language for
a special set of systems.

How your return value of main is transferred to the environment is
not specified by the Standard, which is exactly why we should not make
assumptions about it.

regards
--
jb

(reply address in rot13, unscramble first)
Jul 23 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.