views:

265

answers:

4

Consider this code:

const char* someFun() {
    // ... some stuff
    return "Some text!!"
}

int main()
{
   { // Block: A
      const char* retStr = someFun();
      // use retStr
   }
}

My question is in the function sumFun() where is "some Text!!", stored (i think may be in some static area in ROM) and what will be its scope?

Will the memory pointed by retStr be occupied throughout the program or be released once the block A exits?

--
Thanks

+4  A: 

String will be stored statically in special (usually read-only on modern OS) section of the program binary. Its memory is not allocated (individually for the string, only for total section while loading it to memory) and will not be deallocated.

osgx
That's no necessarily true. What if the binary format you're linking to doesn't support the notion of "read-only sections"? (e.g. most basic COM files)
conio
mamonts doesn't have read only sections too. They have only historic interest.
osgx
even in com file there will be some part (section of file), or several, for storing constants. They will be not marked as read only in segments or in page descriptors, but the idea will be the same.
osgx
That was just an extreme example where it's **not possible** to put the string in a "read only section" (since there are no sections). The point is that this being impossible the standard doesn't impose such a requirement, and therefore a complying compiler/linker might not do it, **even when it is possible**.
conio
Regarding COM files you are absolutely wrong: COM files are **real-mode** "memory snapshots", and even that memory area in which **logically** the linker put all the constants isn't read-only in any way. **Real-mode** doesn't have any memory protection features of that sort.
conio
Ok, edited the answer. Even gcc can put string consts to write-enabled memory.
osgx
@conio, form wiki (sorry): >" COM file can either be very simple, using a single segment, or arbitrarily complex, providing its own memory management system"It will loaded as snapshot, but it can even change the mode to protected.
osgx
That's irrelevant. Windows was also implemented at a time in a COM file: `win.com`, but a COM file **in itself** has no notion of memory protection. **AFTER** the binary is loaded and running its code can do anything, but the binary format itself has no notion of memory protection. You see, the **code** inside the file can cause a transition to protected mode, but a COM file **in itself** doesn't do that. Your argument is analogous to saying that since I can board an airplane with a skateboard it means that skateboards can fly...
conio
@conio, elf itself does not have memory protection too (it is a byte stream). Memory protection is applyed by elf loader either in OS or in dynamic loader (and file can be loaded from disk to memory/pagecache before it will be mapped with right protection). C program compiled in COM will be run AFTER crt. And crt MAY add some protection. COM files can contain info for linker, so code from COM will be run only after loading it by (external to this COM) linker.
osgx
Actually, COM files don't contain information for the linker-loader. They are plain memory snapshots. That's written in the wikipedia article you quoted earlier: *It is very simple; it has no header, and contains no metadata, only code and data.*EXE files on the other hand contain sections that can be marked as read-only, and the Windows loader (which runs in protected mode and is aware of its capabilities) marks the pages corresponding to the EXE section appropriately.
conio
+18  A: 

The C++ Standard does not say where string literals should be stored. It does however guarantee that their lifetime is the lifetime of the program. Your code is therefore valid.

anon
+8  A: 

The "Some text!!" does not have a scope. Scope is a property of a named entity. More precisely, it is a property of the name itself. "Some text!!" is a nameless object - a string literal. It has no name, and therefore any discussions about its "scope" make no sense whatsoever. It has no scope.

What you seem to be asking about is not scope. It is lifetime or storage duration of "Some text!!". String literals in C/C++ have static storage duration, meaning that they live "forever", i.e. as long as the program runs. So, the memory occupied by "Some text!!" is never released.

Just keep in mind (as a side note) that string literals are non-modifyable objects. It is illegal to write into that memory.

AndreyT
correct it is lifetime, not scope, my bad :(
Neeraj
A: 

Will the memory pointed by retStr be occupied throughout the program or be released once the block A exits?

Edit:

It will be not released, but retStr will not be available. (block scope)

const char *ptr;
{   
   const char* retStr = "Scope";
   ptr = retStr;
}   

printf("%s\n", ptr); //prints "Scope"

//printf("%s\n", retStr); //will throw error "retStr undeclared"
N 1.1
it will Not be released only the symbol retStr wouldn't be available
Neeraj
Incorrect. The memory that retStr points to after the execution is static memory. It is allocated when the application starts and is only released (effectively) when the application terminates.
Alan
@all: my mistake, i was thinking about `retStr`. Will change the answer.
N 1.1