int * vs char *

[yugandhar_S]

Hi,

I have a quick question.

The following works:

char *s="hello";
*s="world";

but the following gives a segementation fault:

int *p = 0;
*p = 17;

Could anyone please clarify about this?

yugandhar

 

[Emmanuel Delahaye]

The following works:

No, it doesn't.

char *s="hello";
*s="world";

Initializing a char ('*s' is 's[0]') with an address is a nonsense and your
compiler should complain about that.

You probably meant:

char *s="hello";
s="world";

but the following gives a segmentation fault:

int *p = 0;

This is eq. to

int *p = NULL;

*p = 17;

Dereferencing the NULL pointer invoques an Undefined Behaviour.

 

[Malcolm]

The following works:

char *s="hello";
*s="world";

This works by chance. The variable s is pointer, i.e. it holds an address.
That address is set to the position of the string literal "hello" in memory.
One of the confusing things about C is that * is used both to declare a
pointer (as in your first line) and to dereference a pointer, or take the
thing it points to.
In your second line you are dereferencing the pointer. The memory location
occupied by the "h" of your string literal is now set to the address of the
string literal "world".
It is probable that on your machine a char occupies 1 byte whilst a char *
occupies 4 bytes. C will cope with this situation by silently discarding the
top three bytes of the address. The 'h' of "hello" is thus set to the lowest
byte of the address of "world". This could be anything.

but the following gives a segementation fault:

int *p = 0;
*p = 17;

Could anyone please clarify about this?

p is a pointer which is set to 0, or NULL, probably physical location 0 in
memory.
*p = 17 writes a 17 to physical location zero in memory. On most machines,
this will trigger some sort of error because location zero is special, and
normal application are not allowed to write to it.
NULL pointers (or p == 0) are used extensively in C to say "this pointer
doesn't point to anything".

 

[Dave Thompson]

Works by chance? No, it doesn't work at all. It is an error. Any ANSI C
compiler will complain about the attempt to implicitly convert (char *)
to (char), which is not allowed in C.
Right.



No, as it is written it has undefined behaviour because of the constraint
violation for the conversion without a cast.

A constraint violation requires a diagnostic. *If* the compiler
continues after that diagnostic, e.g. it is only a warning, then yes
the behavior is not defined by the standard, although any implementor
who does something different for an implicit conversion than the same
explicit (casted) one deserves to be boiled in oil. Repeatedly.

Assuming you specify the
conversion with an explicit cast, it is still undefined behaviour because
it is attempting to modify a string literal.

Right.

Assuming you change it to:
char s[] = "hello";
*s = (char)"world";
Then the address of the string literal "world" is converted to char. If the
value does not fit into the integer type, which is likely here, we still have
undefined behaviour.

No, *that* is an implementation-defined (hence documented) result, or
in C99 only the raising of an implementation-defined signal. Still
not portable, and nowhere near correct, but not the full horror of UB.


- David.Thompson1 at worldnet.att.net