where are the strings?

[Thomas Zhu]

Hello,

I know the difference between the two definations.
But I do not know where are they in the memory.
would someone tell me ?

char s[][10]={"good", "morning"}; // at stack?
char *t[] = {"good", "morning"}; // at heap?

thanks in advance.

[Walter Roberson]

In article <11*********************@z14g2000cwz.googlegroups. com>,
Thomas Zhu <zh********@gmail.com> wrote:

I know the difference between the two definations.
But I do not know where are they in the memory.
would someone tell me ? char s[][10]={"good", "morning"}; // at stack?
char *t[] = {"good", "morning"}; // at heap?

Standard C does not know anything about stacks or heaps.

The only distinction in C is whether a variable is static,
auto, or register.

Based upon previous postings, I gather that there are real C
compilers out there for implementations which do not use stacks
or heaps.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

[Christopher Benson-Manica]

Thomas Zhu <zh********@gmail.com> wrote:

I know the difference between the two definations.
But I do not know where are they in the memory.
would someone tell me ? char s[][10]={"good", "morning"}; // at stack?
char *t[] = {"good", "morning"}; // at heap?

The answer here is "We don't know" - it's wholly dependent on your
implementation. However, the strings in the second definition are
likely to end up in a different place than the first; string literals
may well be stored in a special area of memory, which may or may not
be read-only (and you may not modify them, in either case).

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Neil Cerutti]

On 2005-10-27, Thomas Zhu <zh********@gmail.com> wrote:

Hello,

I know the difference between the two definations.
But I do not know where are they in the memory.
would someone tell me ?

char s[][10]={"good", "morning"}; // at stack?
char *t[] = {"good", "morning"}; // at heap?

thanks in advance.

The important difference between the two examples is that the
former's strings will be modifiable, while the latter's will not.

--
Neil Cerutti

[Jordan Abel]

On 2005-10-27, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

In article <11*********************@z14g2000cwz.googlegroups. com>,
Thomas Zhu <zh********@gmail.com> wrote:

I know the difference between the two definations.
But I do not know where are they in the memory.
would someone tell me ?

char s[][10]={"good", "morning"}; // at stack?
char *t[] = {"good", "morning"}; // at heap?

Standard C does not know anything about stacks or heaps.

The only distinction in C is whether a variable is
static,

For which as a convenience we can use the term "data"
auto,
ditto "stack"
or register.
and "register" will do just fine for this

and you forgot malloc - which is what "heap" generally means.
Based upon previous postings, I gather that there are real C
compilers out there for implementations which do not use stacks
or heaps.

Now, in actual answer for his question, that depends on where you
declare this - the string data will be in automatic storage [aka
"stack"] in the first case if declared in a function, or in static
storage if you declared it at the top level of the file. In the
second case, these are string literals and will often be stored in a
nonwritable segment.

[Alan Balmer]

On Thu, 27 Oct 2005 23:28:35 +0000 (UTC), Jordan Abel
<jm****@purdue.edu> wrote:

Standard C does not know anything about stacks or heaps.

The only distinction in C is whether a variable is
static,
For which as a convenience we can use the term "data"

Why is that more "convenient" than "static"? Especially when it
doesn't mean the same thing?

auto,
ditto "stack"

Also no more convenient and much less accurate.

or register.

and "register" will do just fine for this

Thank you ;-)
and you forgot malloc - which is what "heap" generally means.

Based upon previous postings, I gather that there are real C
compilers out there for implementations which do not use stacks
or heaps.

Now, in actual answer for his question, that depends on where you
declare this - the string data will be in automatic storage [aka
"stack"] in the first case if declared in a function, or in static
storage if you declared it at the top level of the file. In the
second case, these are string literals and will often be stored in a
nonwritable segment.

No, the actual answer to his question is "It depends. You should ask
in a newsgroup which knows the answer for whatever implementation you
are using." This could be followed by the (on-topic) statement that
"In most cases, you shouldn't care where it's stored. You should only
care that one form is modifiable, and the other is not."
--
Al Balmer
Balmer Consulting
re************************@att.net

[Jordan Abel]

On 2005-10-27, Alan Balmer <al******@att.net> wrote:
[other people wrote other stuff]

or register.

and "register" will do just fine for this

Thank you ;-)

As long as everyone understands that they're not _really_ registers.

Now, in actual answer for his question, that depends on where you
declare this - the string data will be in automatic storage [aka
"stack"] in the first case if declared in a function, or in static
storage if you declared it at the top level of the file. In the
second case, these are string literals and will often be stored in
a nonwritable segment.

No, the actual answer to his question is "It depends. You should
ask in a newsgroup which knows the answer for whatever
implementation you are using." This could be followed by the
(on-topic) statement that "In most cases, you shouldn't care where
it's stored. You should only care that one form is modifiable, and
the other is not."

And no-one but me actually told him the part about one being
non-modifiable

[Peter Nilsson]

[highly edited...]

Jordan Abel wrote:

static,
data

auto,

stack

or register.

register

and... malloc - heap

Can you tell me why you think that understanding an alternative
paradigm to the standard is important? Particularly when writing code
that is to be maximally portable?

Your response seems typical of people who learn unix or windows
specific programming, and who now seem unable, or at least unwilling,
to actually understand the C language in its own terms.

I've don't understood why specific alternatives are actually
useful! They tend to lead to misunderstandings, in the same way
that people trying to learn C by reading compiler disassemblies
are often confused when they start programming on a different
architectures. It's usually because they started with preconceptions
that, whilst supported within the C language, needn't (and often
don't) apply to different implementations.

Something as simple as focusing on _when_, rather than _where_
objects are stored, is considerably more useful and leads to much
less confusion in the long term (in my experience).
... string literals ... will often be stored in a nonwritable
segment.

Classic example...

This means nothing to someone programming an old mac that doesn't
use anything called a segment. And I can't see why this ostensibly
priceless nugget of information is somehow more relavent than...

"Modifying string literals invokes undefined behaviour."

The latter being applicable to _any_ implementation of the virtual
C machine.

Fundamentally, I'm asking you: why confuse people with
specialisations when the abstraction is straight forward enough,
and more useful?

--
Peter

[Jordan Abel]

On 2005-10-28, Peter Nilsson <ai***@acay.com.au> wrote:

Can you tell me why you think that understanding an alternative
paradigm to the standard is important? Particularly when writing code
that is to be maximally portable?

Your response seems typical of people who learn unix or windows
specific programming, and who now seem unable, or at least unwilling,
to actually understand the C language in its own terms.

I've don't understood why specific alternatives are actually
useful! They tend to lead to misunderstandings, in the same way
that people trying to learn C by reading compiler disassemblies
are often confused when they start programming on a different
architectures. It's usually because they started with preconceptions
that, whilst supported within the C language, needn't (and often
don't) apply to different implementations.

Something as simple as focusing on _when_, rather than _where_
objects are stored, is considerably more useful and leads to much
less confusion in the long term (in my experience).
I think you misunderstand the use of the terms by unix/windows
programmers - i, for example learned "the heap" as a generic term
for malloc-space, years before i learned about the data structure
called a heap. They're just words.

... string literals ... will often be stored in a nonwritable
segment.

Classic example...

This means nothing to someone programming an old mac that doesn't
use anything called a segment.

Neither does my own freebsd system as far as i know [iirc what i am
thinking of are called "sections" on most modern unixes] - it's just
a word.
And I can't see why this ostensibly
priceless nugget of information is somehow more relavent than...

"Modifying string literals invokes undefined behaviour."

Yes, but you didn't say that. I came closer to you than saying that
initially.

Let's define "nonwritable" as "that which an attempt to write to
will either be guaranteed to fail or cause undefined behavior", and
"segment" as any area of memory. There's hardly any more relevant
meaning of those terms that applies to the "C virtual machine" [i
assume you meant 'abstract', not 'virtual']

[Chris Torek]

>On 2005-10-27, Thomas Zhu <zh********@gmail.com> wrote:

I know the difference between the two definations.
But I do not know where are they in the memory.
would someone tell me ?
You are perhaps better off not knowing, in many cases. :-)
char s[][10]={"good", "morning"}; // at stack?
char *t[] = {"good", "morning"}; // at heap?
In article <sl*********************@FIAD06.norwich.edu>
Neil Cerutti <le*******@email.com> wrote:

The important difference between the two examples is that the
former's strings will be modifiable, while the latter's will not.

This is indeed an important difference, but not necessarily
the only one. In particular, the code fragments above might
be incomplete, so that the above is not the entire translation
unit.

Consider the following (complete-program) translation unit:

#include <stdio.h>

char a[] = "hello";
char *b = "world";

char *e(int x) {
return x ? a : b;
}

char *f(int x) {
char c[] = "cello";
char *d = "whorl";

return x ? c : d;
}

int main(void) {
printf("%s %s\n", e(1), e(0));
printf("%s\n", f(0));
return 0;
}

The behavior and output of this program is well-defined, but if
one were to change the second printf() to call f(1), the program
would have undefined behavior and the output would be unpredictable.
On many implementations, the second line of output will contain
some sort of trash, as in the one I used to run it here:

% ./t
hello world
ÜzÓ
/<invalid character deleted>¬z`

The reason for the undefined behavior is that the string in
the array named "c" has automatic duration, lasting only as
long as the array object itself. The array is (at least in
principle) destroyed when f() returns, and on this implementation,
by the time printf() gets around to using the pointer, the
array is in fact destroyed (hence the u-umlaut and so on).

When a string literal is used to initialize an array object, the
characters in the literal simply initialize that object. The scope
and duration of the object are not affected by the string literal.

On the other hand, when a string literal appears in some other
context, its characters are used to initialize an anonymous array
that is -- at least in principle -- read-only, yet nonetheless has
type "array N of char" -- not "array N of const char", even though
"const" would make sense -- where N is the number of "char"s required
to contain the whole literal plus an additional terminating '\0'
byte. Hence, in the code above, "world" and "whorl" both initialize
anonymous objects of type "array 6 of char". The objects so
initialized have static duration, so they last as long as the
program runs (and possibly beyond then; the C Standards sayeth not)
and no scope (they are anonymous, so the concept of scope does not
really apply).

Thus, to go back to the original examples:
char s[][10]={"good", "morning"}; // at stack?
The Standards do not define "a" (much less "the") stack, although
automatic variables behave in a stack-like manner, and a single
stack, or sometimes two stacks -- one for data and one for control
-- are quite common. But if "s" is outside any function, the
variable s is not going to be on the data-stack in typical
implementations; if it is inside a function, it is. In
any case, the type of "s" will be "array 2 of array 10 of char"
and the memory contents can be described pictorially as:

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-...-+
| g | o | o | d |\0 |\0 |\0 |\0 |\0 |\0 | m | o | r | n | ... |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-...-+

The scope and duration of "s" will be the same as that of
any other variable not declared with "static" or "extern",
i.e., depends on whether s is declared within a function.
char *t[] = {"good", "morning"}; // at heap?

In this case, the answer is more complex. Once again, the Standards
do not define the term "heap"; but if we take that word to mean
"the space that malloc() allocates, and free() destroys", the answer
is: no, none of these will be in that space.

Instead, the string "good" will initialize some anonymous array
of type "array 5 of char":

+---+---+---+---+---+
| g | o | o | d |\0 |
+---+---+---+---+---+

This array will live somewhere in memory, possibly in read-only
memory, and will be present and initialized by the time main() is
entered initially; the array will still exist up until the program
exits (and possibly afterward, or perhaps not; as far as the Standard
is concerned, the "program universe" vanishes once the program
exits, and no one cares anymore).

The string "morning" will initialize some other anonymous array,
perhaps somewhere near the one that contains "good\0", perhaps not:

+---+---+---+---+---+---+---+---+
| m | o | r | n | i | n | g |\0 |
+---+---+---+---+---+---+---+---+

This object has type "array 8 of char" and again may (or may not)
be read-only.

Finally, the ordinary variable "t" will be created, with type
"array 2 of pointer to char", initialized so that t[0] points
to the first anonymous object, and t[1] to the second:

+---+---+---+---+---+
_--> | g | o | o | d |\0 |
/ +---+---+---+---+---+
|
|
+-------+-------+
| * | * |
+-------+-------+
|
___________/
/
|
\ +---+---+---+---+---+---+---+---+
`-> | m | o | r | n | i | n | g |\0 |
+---+---+---+---+---+---+---+---+

The duration and scope of the object named "t" will be the same as
that of "s", assuming both are inside (or both outside) a function.

It is possible (but not necessarily the case) that the strings
"good\0" and "morning\0" will actually abut in memory.

If it were important that they did, one could write:

static char strpair[] = "good\0morning";

to initialize a named (non-anonymous) array, give it static duration,
make it read/write (or add "const" to make it read-only), and then
use &strpair[0] instead of "good" and &strpair[5] instead of
"morning". Or one could write, e.g.:

void f(void) {
char *t[2];

t[0] = "good\0morning";
t[1] = t[0] + 5;
... code ...
}

Note that embedded \0 sequences in string literals are copied
through to the objects they initialize. Hence a string literal is
not always the same as the first string within it (because in C,
a "string" is simply a \0-terminated data structure; if the string
literal contains \0 characters, it produces multiple adjacent
strings).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Alan Balmer]

On Thu, 27 Oct 2005 23:48:00 +0000 (UTC), Jordan Abel
<jm****@purdue.edu> wrote:

On 2005-10-27, Alan Balmer <al******@att.net> wrote:
[other people wrote other stuff]

or register.

and "register" will do just fine for this

Thank you ;-)

As long as everyone understands that they're not _really_ registers.

Now, in actual answer for his question, that depends on where you
declare this - the string data will be in automatic storage [aka
"stack"] in the first case if declared in a function, or in static
storage if you declared it at the top level of the file. In the
second case, these are string literals and will often be stored in
a nonwritable segment.

No, the actual answer to his question is "It depends. You should
ask in a newsgroup which knows the answer for whatever
implementation you are using." This could be followed by the
(on-topic) statement that "In most cases, you shouldn't care where
it's stored. You should only care that one form is modifiable, and
the other is not."

And no-one but me actually told him the part about one being
non-modifiable

Both Christopher and Neil did. More precisely, imo.
--
Al Balmer
Balmer Consulting
re************************@att.net

[Michael Wojcik]

In article <sl*******************@random.yi.org>, Jordan Abel <jm****@purdue.edu> writes:

On 2005-10-27, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

Standard C does not know anything about stacks or heaps.

The only distinction in C is whether a variable is
static, auto, or register.

and you forgot malloc - which is what "heap" generally means.

What makes you think Walter forgot malloc? It's not a storage
class, and C does not have "malloc variables".

Other people have - rightly, IMO - already questioned what
advantage your proposed "convenience" terms provide.

--
Michael Wojcik mi************@microfocus.com

We are subdued to what we work in. (E M Forster)

[Jordan Abel]

On 2005-10-28, Michael Wojcik <mw*****@newsguy.com> wrote:

In article <sl*******************@random.yi.org>, Jordan Abel <jm****@purdue.edu> writes:

On 2005-10-27, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

>
> Standard C does not know anything about stacks or heaps.
>
> The only distinction in C is whether a variable is
> static, auto, or register.
and you forgot malloc - which is what "heap" generally means.

What makes you think Walter forgot malloc? It's not a storage
class, and C does not have "malloc variables".

It's a kind of memory. a place where things can exist. I guess I was
thinking "object" rather than variable

as in, char *foo=malloc(10);

the object (*foo) exists in malloc space.
Other people have - rightly, IMO - already questioned what
advantage your proposed "convenience" terms provide.

None at all. My point was that they're just terms, and there's no
reason to harp on someone using "the wrong terms" when it's
perfectly clear what they mean.

[Mark McIntyre]

On Fri, 28 Oct 2005 18:43:03 +0000 (UTC), in comp.lang.c , Jordan Abel
<jm****@purdue.edu> wrote:

None at all. My point was that they're just terms, and there's no
reason to harp on someone using "the wrong terms"
Indeed. So if someone insisted on calling your new car a Mazda when it
was a Maserati,or your wife a porker instead of a corker... thats ok,
they're just terms.

when it's perfectly clear what they mean.

But its manifestly not. Otherwise questions wouldn't get asked about
it...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----