Is it possible sentence?

[Alex]

Hi,

I have a question regarding to string variable.

Please look at below example.
------------------------------
#define STR "ABC"

char *testStr
testStr = STR;
------------------------------

I think above example have no problem.
But I don't know where "ABC" is exist.
Does C compiler make a memory for STR?

-Alex-

 

[Chris Dollin]

I have a question regarding to string variable.

Please look at below example.

(missing

testStr = STR;

(illegal at top level; assume we rewrite to

chat *testStr = STR;
)

Somewhere. Somewhere where it will be valid for the
entire program run. You don't need to know where.

Does C compiler make a memory for STR?

Yes, but irrelevant; STR is a preprocessor symbol and is not visible
at run-time (and need not and usually is not in compiled object code).

 

[Vijay Kumar R Zanvar]

Hi,

I have a question regarding to string variable.

Please look at below example.
------------------------------
#define STR "ABC"

char *testStr
testStr = STR;

This is perfectly correct if it appears inside a function. A statement
in C must always be within a compound block.

------------------------------

I think above example have no problem.
But I don't know where "ABC" is exist.
Does C compiler make a memory for STR?

Your question, in general, is about storage of string literals. The answer
varies under the following situations:

* The Standard recommends the string literal to be a read-only; thus,
allows sharing copies of string with identical text. In this
case, the implementation may store the sting in the code section,
or any other read-only section. This method helps perform some
optimizations.

* Many implementation provide extensions which are, generally, non
portable. One such extension is writable string literals. The
string is, then, stored in the program's static region. Thus, there
would be different copies of string literal of identical text.

Many compilers provide option to control the behaviour of character string
literals. For example, gcc provide a compiler switch, -fwritable-strings, to
store strings in writable data section. By default, GCC merges duplicate
strings, whereas, Borland's Turbo C/C++ doesn't. It provides the following
switches:

-d merge duplicate string on
-d- merge duplicate string off

Many compilers provide pragmas to control, but these are non portable.
The Standard(C99) specifies only few pragmas that are portable, and is out of
scope here.

 

[Vijay Kumar R Zanvar]

Ah..missing semicolon.

 

[Irrwahn Grausewitz]

Hi,

I have a question regarding to string variable.

Please look at below example.
------------------------------
#define STR "ABC"

char *testStr
testStr = STR;
------------------------------

I think above example have no problem.
But I don't know where "ABC" is exist.
Does C compiler make a memory for STR?

No. First, every occurrence of STR is literally replaced with "ABC"
by the C preprocessor. Later in translation "ABC", like every source
code string literal, is translated into an anonymous array object
(in C the term 'object' means 'region of data storage which can hold
values').

Regards

 

[Dan Pop]

I have a question regarding to string variable.

Please look at below example.
------------------------------
#define STR "ABC"

char *testStr;
testStr = STR;

Indeed, it is correct (after fixing an obvious typo).

But I don't know where "ABC" is exist.

It is typically stored in either the data segment or the text segment
of the program. If you can change it at runtime without crashing the
program, then it's probably in the data segment. If the program crashes,
it's in the text segment. Let's see:

fangorn:~/tmp 192> cat test.c
#define STR "ABC"

int main()
{
char *testStr;
testStr = STR;
*testStr = 0;
return *testStr;
}
fangorn:~/tmp 193> gcc test.c
fangorn:~/tmp 194> ./a.out
Segmentation fault

So, it was in the text segment on my system/compiler combo.
Some compilers allow the user to control this aspect:

fangorn:~/tmp 195> gcc -fwritable-strings test.c
fangorn:~/tmp 196> ./a.out
fangorn:~/tmp 197> echo $status
0

Does C compiler make a memory for STR?

The STR identifier exists only during the preprocessing phase. By the
time the proper compilation starts, it has already been replaced by the
"ABC" string literal, so the compiler doesn't even get to "see" it.

Dan

 

[Ralmin]

Note: the semicolon in the above line was added by Dan, and was not in
Alex's original post.

Dan, lest anyone accuse you of turning into another ERT, please strictly
uphold the rules of quoting. The most one should do to quoted text is to
snip out parts or to reflow the text for a consistent line length. It is not
acceptable to silently make additions, changes or improvements to someone's
code. At the least, the quote symbol on that line (>) should be removed to
indicate changes were made.

 

[Jack Klein]

This is perfectly correct if it appears inside a function. A statement
in C must always be within a compound block.


Your question, in general, is about storage of string literals. The answer
varies under the following situations:

* The Standard recommends the string literal to be a read-only; thus,

The Standard makes no recommendations at all as to whether string
literals should be read-only or not. C++ defines string literals as
having type array of const char, but C does not. A C string literal
has the type of array of char, no const.

Modifying a string literal in C is undefined behavior because the
standard specifically states that it is, not because the characters
may or may not be read-only.

 

[Jack Klein]

Indeed, it is correct (after fixing an obvious typo).


It is typically stored in either the data segment or the text segment

Who says C programs have data segments and text segments? Chapter and
verse.

of the program. If you can change it at runtime without crashing the
program, then it's probably in the data segment. If the program crashes,
it's in the text segment. Let's see:

Let's not. A strictly conforming program can't tell what happens when
a string literal is changed, since it ceases to be strictly conforming
when it tries to perform the change.

In most of the environments where the code I get paid to write
executes, the undefined behavior of attempting to modify a string
literal is ... nothing at all. The EPROM or Flash device in which the
string literal is stored is totally unaffected by anything the
processor can do to it in normal execution.

 

[Dan Pop]

Note: the semicolon in the above line was added by Dan, and was not in
Alex's original post.

Why would anyone bother to note such an irrelevant detail? Does it make
any difference to the OP question or to my reply?

Dan, lest anyone accuse you of turning into another ERT, please strictly
uphold the rules of quoting. The most one should do to quoted text is to
snip out parts or to reflow the text for a consistent line length. It is not
acceptable to silently make additions, changes or improvements to someone's
code. At the least, the quote symbol on that line (>) should be removed to
indicate changes were made.

Did you read the rest of my post with your brain engaged? Here's the
relevant part:

>I have a question regarding to string variable.
>
>Please look at below example.
>------------------------------
>#define STR "ABC"
>
>char *testStr;
>testStr = STR;
>------------------------------
>
>I think above example have no problem.

Indeed, it is correct (after fixing an obvious typo).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In your humble opinion, what was the purpose of the parenthetical
remark underlined above?

The intent of the OP was perfectly clear, despite the missing semicolon
in the original code. If I had any good reason to suspect that the OP
omitted it *by ignorance*, I would have pointed out the syntax error.
In the absence of any such reason, it was more constructive to fix the
code AND mention that I've fixed it, rather than waste time uselessly
pointing out the missing semicolon. I keep forgetting semicolons myself,
on a regular basis, because my brain is focused on more important things
when typing C code.

It is not the first time I'm correcting trivial typos in posted code
and expect a much harsher reply the next time you choose to make a
fuss out of it.

Dan

 

[Dan Pop]

^^^^^^^^^
Who says C programs have data segments and text segments?

No one. Do you have the slightest clue about the meaning of the word
"typically"? In context, it means: "it is common practice to". If you
have any sensible objection to my statement above, please make it. But
keep the crap for yourself.

Chapter and verse.

From what?

Let's not. A strictly conforming program can't tell what happens when
a string literal is changed, since it ceases to be strictly conforming
when it tries to perform the change.

Therefore, I used a non-strictly conforming program to make my point.

In most of the environments where the code I get paid to write
executes, the undefined behavior of attempting to modify a string
literal is ... nothing at all.

In most of the environments you're talking about, calling printf (without
defining it) invokes undefined behaviour. So, should I avoid using
printf because of that?

Feel free to flame me when I start talking about segmentation faults or
the ability to alter string literals in comp.arch.embedded. But make the
effort to remember that the implementations we're talking about in c.l.c
are, by default, hosted.

Dan

P.S. And your point was... ?

 

[Jack Klein]

Therefore, I used a non-strictly conforming program to make my point.


In most of the environments you're talking about, calling printf (without
defining it) invokes undefined behaviour. So, should I avoid using
printf because of that?

Feel free to flame me when I start talking about segmentation faults or
the ability to alter string literals in comp.arch.embedded. But make the
effort to remember that the implementations we're talking about in c.l.c
are, by default, hosted.

Dan

P.S. And your point was... ?

What part of:

Let's not. A strictly conforming program can't tell what happens when
a string literal is changed, since it ceases to be strictly conforming
when it tries to perform the change.

....didn't you understand?

Describing what happens once a program invokes undefined behavior is
not a C language issue and is quite off-topic here.

 

[Minti]

What part of:


...didn't you understand?

Describing what happens once a program invokes undefined behavior is
not a C language issue and is quite off-topic here.

So that means that saying that :

"I coded it and @Nasal Daemons@ started flowing out my nose(?)" would
be much better than saying that it might cause Segmentation fault. IMO
opinion when a newbie asks a question it is much better to give a real
perspective as to what *might* happen, rather than using terminology
for which he might spend next half an hour searching the net, and
which _might_ *never* happen.

 

[Dan Pop]

...didn't you understand?

What part of my previous text reflected my failure to understand this
irrelevant remark?

Describing what happens once a program invokes undefined behavior is
not a C language issue and is quite off-topic here.

You're confusing c.l.c and comp.std.c. If you can't tolerate discussions
that go beyond the chapter and verse of the standard, c.l.c is not for
you.

The purpose (or one of the main purposes) of c.l.c is to help people
learn C and practical issues are *as* important as the theoretical ones.
People make programming mistakes and invoke undefined behaviour, as a
result. Understanding the *practical* consequences of invoking undefined
behaviour helps finding mistakes that led to invoking undefined behaviour.

We also recommend people to carefully read and try to understand the
diagnostics generated by their compilers, although there is no chapter
and verse in the standard supporting such a recommendation. Are you
strongly objecting to this recommendation, too? How about the one
about not casting the return value of malloc? There is no chapter and
verse forbidding it, right?

You're kindly invited to remove your head from your arse. The brain
can greatly benefit from the additional oxygen...

Dan

 

[Tak-Shing Chan]

Describing what happens once a program invokes undefined behavior is
not a C language issue and is quite off-topic here.

Google groups search: +"Jack Klein" +"DeathStation" and I
found this:

``On the DeathStation 9000 it might mean launch nuclear
missiles at Antarctica'' -- Jack Klein, 2002-06-22

Tak-Shing