468,765 Members | 1,722 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,765 developers. It's quick & easy.

int * vs char *

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
Nov 13 '05 #1
3 2300
In 'comp.lang.c', yu*********@yahoo.com wrote:
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.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Nov 13 '05 #2

<yu*********@yahoo.com> wrote in message
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".
Nov 13 '05 #3
On Tue, 22 Jul 2003 23:23:14 +1000, "Simon Biber"
<sb****@optushome.com.au> wrote:
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:
<yu*********@yahoo.com> wrote in message
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.


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.

<snip>
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".


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
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Christopher Benson-Manica | last post: by
5 posts views Thread by Sona | last post: by
2 posts views Thread by Peter Nilsson | last post: by
5 posts views Thread by jab3 | last post: by
18 posts views Thread by Pedro Pinto | last post: by
4 posts views Thread by Paul Brettschneider | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.