char string
mangesh
char *p = "xyz" ;
Many books state that compiler stores "xyz" in memory and returns
pointer to that memory
which is assigned to p . My question is , in what type of memory ,
heap or stack ?
Regards
Mangesh .
akiross
gold...@signalsguru.net
akiross wrote:
> I think stack, since xyz is a constant statically allocated.
I don't know what the standard says, but wouldn't it depend on where
the statement was made? If it were global, wouldn't the memory be
allocated before the program started running? In that case, I don't
think it could be on the stack. It might be in an initialization
section.
Richard G. Riley
> I think stack, since xyz is a constant statically allocated.
>
He hasnt specified *where* he has done this declaration so you cant
state whether it is static/heap or not : to be more specific if he is
writing this line in a function as opposed to "global declarations"
outside of any function definitions then this is one thing, inside
functions is another. Inside functions, without the static keyword
then it is a stack based allocation and you cant access it reliably at
function return. Inside functions with "static" it is probably heap and
fine to return a pointer to the data for access by calling functions.
What does the standard say about this?
webs...@gmail.com
Neither. It can be passed out to higher scopes, even after the scope
of p ends (so its not on the stack unless its in a scope as high as
main().) You cannot reliably call free on it, or any containing memory
object, meaning its not in the heap.
The memory exists statically. That is, it occupies the same sort of
memory as globals do though the scope may differ. In the real world,
this is usually put into a memory segment called the init segment which
is similar to the data segment, but may have other attributes, such as
being "read-only".
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
pete
It says that you're clueless on this matter.
"The stack" and "the heap"
are not concerns of the C programming language.
An object refered to by a string literal such as "xyz",
has static duration,
regardless of whether it's inside or outside of a function.
Objects with static duration
are initialised before main starts to execute.
--
pete
W Marsh
Which is why these things are usually declared and passed around as
"const char*". Bear that in mind, original poster.
Jaspreet
I was wondering if the standard actually talks of stack or heap. I
guess not. But again I am playing a guessing game.
I would rather say that the memory is statically linked so you can
access the data even after you have exited the function.
Oh, btw what should my reply be to an interviewer who asks this
question ? I tried reasoning with him (and thats not in one interview
but many) in most polite terms (AFAIK) with above statements but he
would not listen. Please let me know what my response be.
Keith Thompson
> mangesh wrote:
>> When we write
>>
>> char *p = "xyz" ;
>>
>> Many books state that compiler stores "xyz" in memory and returns
>> pointer to that memory
>> which is assigned to p . My question is , in what type of memory ,
>> heap or stack ?
>>
>> Regards
>> Mangesh .
>
> I was wondering if the standard actually talks of stack or heap. I
> guess not. But again I am playing a guessing game.
It doesn't.
> I would rather say that the memory is statically linked so you can
> access the data even after you have exited the function.
I'd say statically allocated, not statically linked.
> Oh, btw what should my reply be to an interviewer who asks this
> question ? I tried reasoning with him (and thats not in one interview
> but many) in most polite terms (AFAIK) with above statements but he
> would not listen. Please let me know what my response be.
Storage duration is described in C99 6.2.4.
Many C implementations do use a "stack" (for objects with "automatic
storage duration" and other per-call data) and a "heap" (for objects
with "allocated storage duration"). It's unlikely that such an
implementation would use either stack or heap for string literals.
This probably isn't the best place to ask about interview strategies.
Personally, if I know I'm right about something during a job
interview, I'm not going to back down because the interviewer thinks
he's smarter than I am. (And it's always possible the interviewer is
deliberately testing me.) But I take absolutely no responsibility for
the consequences of treating this observation as advice.
--
Keith Thompson (The_Other_Keith) ks...@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.
webs...@gmail.com
If you need the job then say its on the stack because you cannot call
free() on it, or any containing object. Then if you get the job
compile the source yourrself, decompile it, then show him that it is in
the init segment. Then point him to documentation about how your OS
loads segments into memory, and that segments are not part of any
"stack".
If you don't need the job that badly, or you reject the job for the
content of this question (and possibly others) then tell him to compile
it up for himself, trace it with a debugger and he will see that it is
neither on the stack, nor in the heap (the address ranges will almost
surely not match up -- and on a standard x86 you will *know* its not on
the stack because its not using stack instructions to access it). If
the interviewer is using the latest MS Visual studio, tell him to try
to execute p[0] = 'x', and ask him which of the heap or the stack he
thinks can contain read-only memory.
webs...@gmail.com
If you need the job then say its on the stack because you cannot call
pete
I wouldn't have listened either.
It's not a linkage issue.
The object refered to by a string literal has "static duration".
Scope and Linkage are separate issues, related to each other.
Stack and heap questions, as in "the stack" and "the heap",
belong on a newsgroup that deals with the particular
implementation involved.
Portable implementations of qsort as a heapsort,
or qsort with a stack instead of recursion,
might be on topic here.
--
pete
CBFalconer
>
... snip ...
>
> If you don't need the job that badly, or you reject the job for
> the content of this question (and possibly others) then tell him
> to compile it up for himself, trace it with a debugger and he
> will see that it is neither on the stack, nor in the heap (the
> address ranges will almost surely not match up -- and on a
> standard x86 you will *know* its not on the stack because its
> not using stack instructions to access it). If the interviewer
> is using the latest MS Visual studio, tell him to try to execute
> p[0] = 'x', and ask him which of the heap or the stack he thinks
> can contain read-only memory.
I think the presence of two copies of this reply, with posting
times separated by 90 minutes, from someone whom I assume knows
better than to double post, settles the fact that these things are
another artifact of the broken google interface.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Default User
[snip]
> I think the presence of two copies of this reply, with posting
> times separated by 90 minutes, from someone whom I assume knows
> better than to double post, settles the fact that these things are
> another artifact of the broken google interface.
At various times, Google will have a problem where it reports that a
message had an error in posting, but it's actually gone out fine. This
will trick people into multiple postings. The past few days it's seemed
like this has been happening with some frequency.
Brian
Jaspreet
Keith Thompson wrote:
> "Jaspreet" <jsingh...@gmail.com> writes:
> > mangesh wrote:
> >> When we write
> >>
> >> char *p = "xyz" ;
> >>
> >> Many books state that compiler stores "xyz" in memory and returns
> >> pointer to that memory
> >> which is assigned to p . My question is , in what type of memory ,
> >> heap or stack ?
> >>
> >> Regards
> >> Mangesh .
> >
> > I was wondering if the standard actually talks of stack or heap. I
> > guess not. But again I am playing a guessing game.
>
> It doesn't.
>
> > I would rather say that the memory is statically linked so you can
> > access the data even after you have exited the function.
>
> I'd say statically allocated, not statically linked.
Oh! yes, not sure why I wrote linked instead of allocation. Thanks for
pointing that out.
>
> > Oh, btw what should my reply be to an interviewer who asks this
> > question ? I tried reasoning with him (and thats not in one interview
> > but many) in most polite terms (AFAIK) with above statements but he
> > would not listen. Please let me know what my response be.
>
> Storage duration is described in C99 6.2.4.
>
> Many C implementations do use a "stack" (for objects with "automatic
> storage duration" and other per-call data) and a "heap" (for objects
> with "allocated storage duration"). It's unlikely that such an
> implementation would use either stack or heap for string literals.
>
> This probably isn't the best place to ask about interview strategies.
> Personally, if I know I'm right about something during a job
> interview, I'm not going to back down because the interviewer thinks
> he's smarter than I am. (And it's always possible the interviewer is
> deliberately testing me.) But I take absolutely no responsibility for
> the consequences of treating this observation as advice.
Actually tried this strategy a couple of times with no luck. :(
Jaspreet
CBFalconer
If that had been the case the posting times would be quite
similar. The 90 minute delta is the key clue here. Unless Paul
remembers what happened.
webs...@gmail.com
> webs...@gmail.com wrote:
> ... snip ...
> > If you don't need the job that badly, or you reject the job for
> > the content of this question (and possibly others) then tell him
> > to compile it up for himself, trace it with a debugger and he
> > will see that it is neither on the stack, nor in the heap (the
> > address ranges will almost surely not match up -- and on a
> > standard x86 you will *know* its not on the stack because its
> > not using stack instructions to access it). If the interviewer
> > is using the latest MS Visual studio, tell him to try to execute
> > p[0] = 'x', and ask him which of the heap or the stack he thinks
> > can contain read-only memory.
>
> I think the presence of two copies of this reply, with posting
> times separated by 90 minutes, from someone whom I assume knows
> better than to double post, settles the fact that these things are
> another artifact of the broken google interface.
Uhh ... no, I actually pressed post twice. I have been using a broken
mouse that's been screwing me up lately. The people at Google know
what race condition is, even if the hardware manufacturers at Microsoft
do not. I've since upgraded to a mouse by Logitech, and hopefully this
sort of thing won't happen in the future.
Keith Thompson
[...]
> Uhh ... no, I actually pressed post twice. I have been using a broken
> mouse that's been screwing me up lately. The people at Google know
> what race condition is, even if the hardware manufacturers at Microsoft
> do not. I've since upgraded to a mouse by Logitech, and hopefully this
> sort of thing won't happen in the future.
So after you press the "post" button, Google leaves the button active?
Sheesh!
webs...@gmail.com
> webs...@gmail.com writes:
> [...]
> > Uhh ... no, I actually pressed post twice. I have been using a broken
> > mouse that's been screwing me up lately. The people at Google know
> > what race condition is, even if the hardware manufacturers at Microsoft
> > do not. I've since upgraded to a mouse by Logitech, and hopefully this
> > sort of thing won't happen in the future.
>
> So after you press the "post" button, Google leaves the button active?
No, after I pressed post -- I don't know if my mouse actually sent the
message or not, unless Google is reacting very quickly; sometimes it
does, sometimes it does not (and sometimes it responds with a sever
error but you can always go back and repost without losing your post).
So I pressed post again thinking my mouse click hadn't gone through.
Whatever, the point is that it was a user error motivated by bad
hardware. You can try to accuse Google of having too much response
variance, but I am not sure that isn't true of just about every USENET
server out there as well.
Chris Smith
> Whatever, the point is that it was a user error motivated by bad
> hardware. You can try to accuse Google of having too much response
> variance, but I am not sure that isn't true of just about every USENET
> server out there as well.
Nah, the point is to criticize Google for not handling the multiple
submit problem, which is a basic thing to do for pretty much any web
application in the world. It shouldn't matter how many times you click
the submit button.
--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Rod Pemberton
"Chris Smith" <cds...@twu.net> wrote in message
news:MPG.1eac561ba...@news.altopia.net...
> <webs...@gmail.com> wrote:
> > Whatever, the point is that it was a user error motivated by bad
> > hardware. You can try to accuse Google of having too much response
> > variance, but I am not sure that isn't true of just about every USENET
> > server out there as well.
>
> Nah, the point is to criticize Google for not handling the multiple
> submit problem, which is a basic thing to do for pretty much any web
> application in the world. It shouldn't matter how many times you click
> the submit button.
>
Posting complaints _here_ about Google related posts improves nothing...
Google complaints should be directed to Googles complaint department.
RP
Keith Thompson
[...]
> Posting complaints _here_ about Google related posts improves nothing...
Not true. There are workarounds, as you know perfectly well.
> Google complaints should be directed to Googles complaint department.
Yes, that too.
webs...@gmail.com
> <webs...@gmail.com> wrote:
> > Whatever, the point is that it was a user error motivated by bad
> > hardware. You can try to accuse Google of having too much response
> > variance, but I am not sure that isn't true of just about every USENET
> > server out there as well.
>
> Nah, the point is to criticize Google for not handling the multiple
> submit problem, which is a basic thing to do for pretty much any web
> application in the world. It shouldn't matter how many times you click
> the submit button.
Right -- so I'm sure I pressed back, then post again. Remember that I
didn't know whether it was my failed mouse hardware or just Google
being slow. Pressing back doesn't lose the data, so that's the
deterministic procedure I chose.
Its not a Google synchronization problem, since I literally submitted
the post twice; unless you expect Google to see that its clearly the
same input and that it should squash the "dual" post. That's plausible
-- but its a *rare* problem. Remember, I needed to have knowingly
failing hardware with a willingness to continue to use it for me to use
Google to double post incorrectly like this. I think the standard
should be if you see that happening on a regular basis, which I don't
think is the case.
Keith Thompson
It is. We regularly see multiple identical postings from Google,
typically less than a minute apart.
Karl Malbrain
Google could easily encode an identifier on the submit button to
identify multpile posts. They have poor interface logic. karl m