pointer and storage

[dis_is_eagle@yahoo.com]

Hi.I have a question on the following statement.

char* a="hello";

The question is where "hello" gets stored.Is it in some static area
,stack or heap.I have observed that attempting to modify "hello"
results in segmentation fault.Thanks for any help.

Eric

[deepak]

Re: pointer and storage


dis_is_eagle@ya hoo.com wrote:

Hi.I have a question on the following statement.
>
char* a="hello";
>
The question is where "hello" gets stored.Is it in some static area
,stack or heap.I have observed that attempting to modify "hello"
results in segmentation fault.Thanks for any help.

The *a will be stored in the readonly part of the data area.
Thats the reason behind the segmenatation fault.

-Deepak.

>
Eric

[Richard Heathfield]

Re: pointer and storage

dis_is_eagle@ya hoo.com said:

Hi.I have a question on the following statement.
>
char* a="hello";
>
The question is where "hello" gets stored.Is it in some static area
,stack or heap.

It depends on the implementation. No implementation is required to use
stacks or heaps.

You would be well-advised to use const char * rather than mere char *.

I have observed that attempting to modify "hello"
results in segmentation fault.

The behaviour resulting from modifying a constant string is undefined. A
segmentation fault is one possible result. The absence of a segmentation
fault is another possible result. And the destruction of Rome by fire is
another possible result.


--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Re: pointer and storage

dis_is_eagle@ya hoo.com posted:

char* a="hello";

This is a definition of a non-const pointer to a non-const char. It also
initialises the pointer to the address of a string literal (which is il-
advised.)

The question is where "hello" gets stored.Is it in some static area
,stack or heap.I have observed that attempting to modify "hello"
results in segmentation fault.Thanks for any help.

The following two programs are equivalent:

/* Program 1 */

int main(void)
{
char const *p = "Hello"; return 0;
}

/* Program 2 */

char const str_literal1[] = {'H','e','l','l ','o',0};

#define LITERAL1 (*(char(*)[sizeof str_literal1])&str_literal 1)

int main(void)
{
char const *p = LITERAL1; return 0;
}

--

Frederick Gotham

[Ark]

Re: pointer and storage

Richard Heathfield wrote:

dis_is_eagle@ya hoo.com said:
>

>Hi.I have a question on the following statement.
>>
> char* a="hello";
>>
>The question is where "hello" gets stored.Is it in some static area
>,stack or heap.

>
It depends on the implementation. No implementation is required to use
stacks or heaps.
>
You would be well-advised to use const char * rather than mere char *.
>

>I have observed that attempting to modify "hello"
>results in segmentation fault.

>
The behaviour resulting from modifying a constant string is undefined. A
segmentation fault is one possible result. The absence of a segmentation
fault is another possible result. And the destruction of Rome by fire is
another possible result.
>
>

I am confused profoundly.
I always thought that where the string literals are stored (RO vs. RW)
is implementation-defined (and decent compilers would allow me to choose
my way with a command-line switch).
However, the /type/ of (a pointer to) a string literal is char *,
regardless of the switch, or so I read the standard a while ago.
So the statement
*a='a';
must compile OK *without diagnostics* and then cause or not cause
undefined behavior depending on implementation-defined behavior.

<OTBTW, as an embedded type, I talked myself out of using compound
literals because they end up in my scarce RAM. (IAR EWARM 4.40
toolchain.) I find it odd that IAR puts string literals, which are, at
least conceptually, compound literals, in RO and true (syntactically)
compound literals, in RW. </OT>

Can anyone shed a bright light on this?
Thank you,
- Ark

[Ben Pfaff]

Re: pointer and storage

Ark <akhasin@macroe xpressions.comw rites:

I am confused profoundly.
I always thought that where the string literals are stored (RO vs. RW)
is implementation-defined (and decent compilers would allow me to choose
my way with a command-line switch).

The Standard doesn't say, so yes, the location of string literals
is defined by an implementation.

However, the /type/ of (a pointer to) a string literal is char *,
regardless of the switch, or so I read the standard a while ago.
So the statement
*a='a';
must compile OK *without diagnostics* and then cause or not cause
undefined behavior depending on implementation-defined behavior.

No compiler is required to compile anything without diagnostics.
The Standard does not restrict an implementation from diagnosing
anything at all. It does *require* a diagnostic for many
programs, but it does not *forbid* diagnostics for other
programs.

Furthermore, the statement in question yields undefined behavior,
so the program is not strictly conforming. Implementations are
only required to successfully translate and execution strictly
conforming programs. The Standard does not clearly distinguish
translation time and runtime, so one cannot even say that the
program should be successfully translated and then executed as
undefined behavior.
--
Go not to Usenet for counsel, for they will say both no and yes.

[Keith Thompson]

Re: pointer and storage

Ark <akhasin@macroe xpressions.comw rites:

Richard Heathfield wrote:

[...]

>The behaviour resulting from modifying a constant string is
>undefined. A segmentation fault is one possible result. The absence
>of a segmentation fault is another possible result. And the
>destruction of Rome by fire is another possible result.

It would be clearer to use the term "string literal" rather than
"constant string".

I am confused profoundly.
I always thought that where the string literals are stored (RO vs. RW)
is implementation-defined

Yes.

(and decent compilers would allow me to
choose my way with a command-line switch).

That's debatable. I don't see much advantage in allowing string
literals to be modifiable (except *maybe* to handle old and broken
code).

However, the /type/ of (a pointer to) a string literal is char *,
regardless of the switch, or so I read the standard a while ago.

Yes.

So the statement
*a='a';
must compile OK *without diagnostics* and then cause or not cause
undefined behavior depending on implementation-defined behavior.

The following:
char *a = "hello";
*a = 'a';
(assuming it appears in an appropriate context) is legal (it violates
no syntax rules or constraints), and a conforming compiler must accept
it. But, as always, a compiler is free to issue any diagnostics it
likes. The standard requires diagnostics in certain cases; it never
forbids them.

If the initialization is executed, it invokes undefined behavior. The
undefined behavior is unconditional, though the effects of the
undefined behavior can be literally anything. There is no
implementation-defined behavior involved (implementation-defined
behavior must be documented by the implementation, and there is no
documentation requirement here).

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Re: pointer and storage

Ben Pfaff <blp@cs.stanfor d.eduwrites:

Ark <akhasin@macroe xpressions.comw rites:

>I am confused profoundly.
>I always thought that where the string literals are stored (RO vs. RW)
>is implementation-defined (and decent compilers would allow me to choose
> my way with a command-line switch).

>
The Standard doesn't say, so yes, the location of string literals
is defined by an implementation.

But it's not "implementa tion-defined" (i.e., the implementation isn't
required to document its choice).

[snip]

Furthermore, the statement in question yields undefined behavior,
so the program is not strictly conforming. Implementations are
only required to successfully translate and execution strictly
conforming programs. The Standard does not clearly distinguish
translation time and runtime, so one cannot even say that the
program should be successfully translated and then executed as
undefined behavior.

I don't think that's true. For example, this program:

#include <stdio.h>
#include <limits.h>
int main (void)
{
printf("INT_MAX = %d\n", INT_MAX);
return 0;
}

is not strictly conforming, since it produces output that depends on
implementation-defined behavior, but I don't believe an implementation
may reject it on that basis.

"Strictly conforming" programs are a very narrow class, and
"conforming " programs are a very wide class ("conforming " programs can
depend on any arbitrary compiler extensions). The standard doesn't
seem to have a name for the class of programs that must be accepted,
but whose behavior may depend on the implementation.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Frederick Gotham]

Re: pointer and storage

Keith Thompson posted:

For example, this program:
>
#include <stdio.h>
#include <limits.h>
int main (void)
{
printf("INT_MAX = %d\n", INT_MAX);
return 0;
}
>
is not strictly conforming, since it produces output that depends on
implementation-defined behavior, but I don't believe an implementation
may reject it on that basis.

Are you saying that there's something wrong with that program? It seems
perfectly alright to me.

--

Frederick Gotham

[pete]

Re: pointer and storage

deepak wrote:

>
dis_is_eagle@ya hoo.com wrote:

Hi.I have a question on the following statement.

char* a="hello";

The question is where "hello" gets stored.Is it in some static area
,stack or heap.I have observed that attempting to modify "hello"
results in segmentation fault.Thanks for any help.

>
The *a will be stored in the readonly part of the data area.

The rules of C, neither require nor prohibit
a string literal being stored in read only memory.

Thats the reason behind the segmenatation fault.

--
pete

[pete]

Re: pointer and storage

Keith Thompson wrote:

>
Ben Pfaff <blp@cs.stanfor d.eduwrites:

Ark <akhasin@macroe xpressions.comw rites:

I am confused profoundly.
I always thought that where the string literals are stored (RO vs. RW)
is implementation-defined (and decent compilers would allow me to choose
my way with a command-line switch).

The Standard doesn't say, so yes, the location of string literals
is defined by an implementation.

>
But it's not "implementa tion-defined" (i.e., the implementation isn't
required to document its choice).
>
[snip]
>

Furthermore, the statement in question yields undefined behavior,
so the program is not strictly conforming. Implementations are
only required to successfully translate and execution strictly
conforming programs. The Standard does not clearly distinguish
translation time and runtime, so one cannot even say that the
program should be successfully translated and then executed as
undefined behavior.

>
I don't think that's true. For example, this program:
>
#include <stdio.h>
#include <limits.h>
int main (void)
{
printf("INT_MAX = %d\n", INT_MAX);
return 0;
}
>
is not strictly conforming, since it produces output that depends on
implementation-defined behavior, but I don't believe an implementation
may reject it on that basis.
>
"Strictly conforming" programs are a very narrow class, and
"conforming " programs are a very wide class ("conforming " programs can
depend on any arbitrary compiler extensions). The standard doesn't
seem to have a name for the class of programs that must be accepted,
but whose behavior may depend on the implementation.

"Correct program" comes pretty close.

N869
4. Conformance

[#3] A program that is correct in all other aspects,
operating on correct data, containing unspecified behavior
shall be a correct program and act in accordance with
5.1.2.3.

--
pete

[Keith Thompson]

Re: pointer and storage

Frederick Gotham <fgothamNO@SPAM .comwrites:

Keith Thompson posted:

>For example, this program:
>>
>#include <stdio.h>
>#include <limits.h>
>int main (void)
>{
> printf("INT_MAX = %d\n", INT_MAX);
> return 0;
>}
>>
>is not strictly conforming, since it produces output that depends on
>implementati on-defined behavior, but I don't believe an implementation
>may reject it on that basis.

>
Are you saying that there's something wrong with that program? It seems
perfectly alright to me.

No, not at all. I was responding to what Ben Pfaff wrote (and you
snipped) upthread:

| Furthermore, the statement in question yields undefined behavior,
| so the program is not strictly conforming. Implementations are
| only required to successfully translate and execution strictly
| conforming programs.

The program is not strictly conforming, but it's still perfectly
valid.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Frederick Gotham]

Re: pointer and storage

Keith Thompson posted:

>>#include <stdio.h>
>>#include <limits.h>
>>int main (void)
>>{
>> printf("INT_MAX = %d\n", INT_MAX);
>> return 0;
>>}

>
The program is not strictly conforming, but it's still perfectly
valid.

Why isn't that program strictly conforming?

--

Frederick Gotham

[Ben Pfaff]

Re: pointer and storage

pete <pfiland@mindsp ring.comwrites:

Keith Thompson wrote:

>"Strictly conforming" programs are a very narrow class, and
>"conforming " programs are a very wide class ("conforming " programs can
>depend on any arbitrary compiler extensions). The standard doesn't
>seem to have a name for the class of programs that must be accepted,
>but whose behavior may depend on the implementation.

>
"Correct program" comes pretty close.

That's a good name. I'll try to remember that.

When I wrote my earlier article in this thread, I knew that
"strictly conforming" was not a perfect term, but I didn't have a
better one and didn't feel like adding a lot of qualifiers or an
extended explanation.
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield

[Keith Thompson]

Re: pointer and storage

Frederick Gotham <fgothamNO@SPAM .comwrites:

Keith Thompson posted:

>>>#include <stdio.h>
>>>#include <limits.h>
>>>int main (void)
>>>{
>>> printf("INT_MAX = %d\n", INT_MAX);
>>> return 0;
>>>}

>>
>The program is not strictly conforming, but it's still perfectly
>valid.

>
>
Why isn't that program strictly conforming?

C99 4p5:

A _strictly conforming program_ shall use only those features of
the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior, and
shall not exceed any minimum implementation limit.

The program's behavior is implementation-defined, since it depends on
the implementation-defined value of INT_MAX.

(You just downloaded n1124, so you could have looked up the definition
yourself.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.