Asp Forum - int * vs char *

unknown

6/21/2011 9:50:00 PM

Hi Forum,

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 me about this?

yugandhar

52 Answers

John Gordon

6/21/2011 9:59:00 PM

In <itr3lm$i8j$1@speranza.aioe.org> yugandhar <nospam@nospam.com> writes:

> Hi Forum,

> I have a quick question.

> The following works:

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

It shouldn't work. A character pointer declared in that way should be
non-writable. It's an accident that it "worked" (did the wrong thing)
for you.

> but the following gives a segementation fault:

> int *p = 0;
> *p = 17;

> Could anyone please clarify me about this?

Setting a pointer equal to zero is a special case.

Zero is another way of saying NULL. So when you declare a pointer that
is equal to zero, it's really a NULL pointer. It doesn't point anywhere.

So, when you say "Insert 17 at the location pointed to by this pointer",
it has no place to put the value 17, since you told it to point nowhere.

--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

Ian Collins

6/21/2011 10:00:00 PM

On 06/22/11 09:49 AM, yugandhar wrote:
> Hi Forum,
>
> I have a quick question.
>
> The following works:
>
> char *s="hello";
> *s="world";

It is certainly not guaranteed to work. It would barf on any of the
compilers I use. These all place string literals in a write only segment.

> but the following gives a segementation fault:
>
> int *p = 0;
> *p = 17;
>
> Could anyone please clarify me about this?

You are invoking the demons of undefined behaviour.

--
Ian Collins

Ike Naar

6/21/2011 10:19:00 PM

On 2011-06-21, yugandhar <nospam@nospam.com> wrote:
> The following works:

In what way do you think it works?

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

You're assigning a pointer-to-char to a char.
That doesn't work. Your compiler should have issued a diagnostic.

> but the following gives a segementation fault:
>
> int *p = 0;
> *p = 17;

p is a null pointer; you're trying to dereference it; don't do that.

> Could anyone please clarify me about this?

Sorry.

Keith Thompson

6/21/2011 10:42:00 PM

yugandhar <nospam@nospam.com> writes:
> 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 me about this?

It's already been explained why "*p = 17;" blows up, but I don't believe
that the first block of code is what you actually compiled.

s is of type char*, so *s is of type char. You're attempting to assign
a string literal (which will decay to char*) to a char object. Early
pre-ANSI C compilers might have accepted that without complaint,
implicitly treating the pointer value as an integer and then narrowing
it to one byte, but in modern C it's a constraint violation, and any
compiler that doesn't at least warn you about it is broken.

Even if you corrected the type mismatch by writing:

*s = 'w';

your program's behavior would be undefined. s points to a string
literal (more precisely, it points to the first element of the static
array associated with the string literal), and any attempt to modify a
string literal has undefined behavior.

I can't be sure what your actual code looks like, but the most plausible
variant I can think of is:

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

That's perfectly legal; it stores the address of the string "world" in
the variable s.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Shao Miller

6/21/2011 11:34:00 PM

On 6/21/2011 4:49 PM, yugandhar wrote:
> Hi Forum,
>
> I have a quick question.
>
> The following works:
>
> char *s="hello";
> *s="world";
>

The type of 's' is 'char *'.

The type of '*s' is 'char'.

The type of '"world"' is not 'char'.

So the last line up above is erroneous.

> but the following gives a segementation fault:
>
> int *p = 0;
> *p = 17;
>

The type of 'p' is 'int *'.

The type of '*p' is 'int'.

Since 'p' is a null pointer, use of '*p' is undefined behaviour. That
explains your segmentation fault.

> Could anyone please clarify me about this?

Maybe.

int my_int = 13;
^^^--type

int my_int = 13;
^^^^^^--object identifier

int * foo, * bar;
^^^-^--type

int * foo, * bar;
^^^--object identifier

int * foo, * bar;
^^^--------^--type

int * foo, * bar;
^^^--object identifier

Also:

int my_int = 13;

is similar to:

int my_int;
my_int = 13;

A different example:

int * ip = &my_int;

is similar to:

int * ip;
ip = &my_int;

and not:

int * ip;
*ip = &my_int;

Morris Keesan

6/22/2011 12:26:00 AM

On Tue, 21 Jun 2011 17:58:50 -0400, John Gordon <gordon@panix.com> wrote:

> In <itr3lm$i8j$1@speranza.aioe.org> yugandhar <nospam@nospam.com> writes:
>
>> Hi Forum,
>
>> I have a quick question.
>
>> The following works:
>
>> char *s="hello";
>> *s="world";
>
> It shouldn't work. A character pointer declared in that way should be
> non-writable. It's an accident that it "worked" (did the wrong thing)
> for you.

Not the declaration, but the initialization (making s point to a string
literal). But whether the pointed-to char is writable is undefined:
"should be non-writable" is a bit of an overstatement. But it should be
treated as unwritable by the programmer, even if not by an implementation.

--
Morris Keesan -- mkeesan@post.harvard.edu

Eric Sosman

6/22/2011 1:47:00 AM

On 6/21/2011 5:49 PM, yugandhar wrote:
> Hi Forum,
>
> I have a quick question.
>
> The following works:
>
> char *s="hello";
> *s="world";

Get a new compiler. Or, possibly, post your question to a forum
devoted to the language you're using: It's not C. (Or, possibly,
post the actual code you're asking about rather than a paraphrase.)

> but the following gives a segementation fault:
>
> int *p = 0;
> *p = 17;

In C, if you're using C, the first line declares a pointer-to-int
and initializes it with the value usually known as NULL, the "pointer
to nowhere." The second line attempts to store 17 at the location
"nowhere," and things go haywire. (Technically, "the behavior is
undefined" -- "haywire" is a reasonable shorthand.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

Stephen Sprunk

6/22/2011 2:29:00 AM

On 21-Jun-11 16:49, yugandhar wrote:
> The following works:
>
> char *s="hello";
> *s="world";

It does?

% cat foo.c
#include <stdio.h>
int main(void) {
char *s="hello";
*s="world";
puts(s);
}
% gcc foo.c
foo.c: In function â??mainâ??:
foo.c:4: warning: assignment makes integer from pointer without a cast
% ./a.out
Segmentation fault

What is the shortest _compilable_ program that "works" on your
implementation? Does your compiler generate any warning messages that
indicate undefined behavior, as mine does?

> but the following gives a segementation fault:
>
> int *p = 0;
> *p = 17;

You're dereferencing a null pointer here, which is also undefined
behavior. However, my compiler isn't smart enough to notice that
problem; it just crashes when executed--for a somewhat different reason
than the former example.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Barry Briggs

6/22/2011 8:29:00 AM

Keith Thompson wrote:

> Even if you corrected the type mismatch by writing:
>
> char *s = "hello";
> *s = 'w';
>
> your program's behavior would be undefined. s points to a string
> literal (more precisely, it points to the first element of the static
> array associated with the string literal), and any attempt to modify a
> string literal has undefined behavior.

Since modifying a character string literal already has UB in
the current standard, then why doesn't the next standard
specify that string literal have type const char[] instead
of just char[] ?

Regards.

Shao Miller

6/22/2011 10:24:00 AM

On 6/22/2011 3:28 AM, Noob wrote:
> Keith Thompson wrote:
>
>> Even if you corrected the type mismatch by writing:
>>
>> char *s = "hello";
>> *s = 'w';
>>
>> your program's behavior would be undefined. s points to a string
>> literal (more precisely, it points to the first element of the static
>> array associated with the string literal), and any attempt to modify a
>> string literal has undefined behavior.
>
> Since modifying a character string literal already has UB in
> the current standard, then why doesn't the next standard
> specify that string literal have type const char[] instead
> of just char[] ?

Undefined behaviour implies "non-portable," in my view. But why remove
an implementation's freedom to define string literals' storage as writable?

comp.lang.c

int * vs char *

unknown

John Gordon

Ian Collins

Ike Naar

Keith Thompson

Shao Miller

Morris Keesan

Eric Sosman

Stephen Sprunk

Barry Briggs

Shao Miller

x Login to ForumsZone