35

Consider this code:

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

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

In the function someFun(), where is "Some text!!" stored (I think it may be in some static area of ROM) and what is its scope lifetime?

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

johnchen902
  • 9,531
  • 1
  • 27
  • 69
sud03r
  • 19,109
  • 16
  • 77
  • 96
  • you may also take a look on this question: http://stackoverflow.com/questions/267114/scope-of-string-literals – quinmars Apr 05 '10 at 20:29

4 Answers4

53

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.

  • 2
    Could you reference the (draft) standard? – mandrake Mar 10 '21 at 16:12
  • Not official, but this may help - https://en.cppreference.com/w/cpp/language/string_literal#:~:text=fwide-exec-charset.-,String%20literals%20have%20static%20storage%20duration,String,-literals%20can%20be – Md Enzam Hossain Sep 22 '21 at 20:46
34

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.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
5

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
  • 90,338
  • 53
  • 357
  • 513
  • 3
    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 Apr 05 '10 at 18:04
  • 1
    mamonts doesn't have read only sections too. They have only historic interest. – osgx Apr 05 '10 at 21:01
  • 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 Apr 05 '10 at 21:03
  • 1
    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 Apr 05 '10 at 21:04
  • 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 Apr 05 '10 at 21:07
  • Ok, edited the answer. Even gcc can put string consts to write-enabled memory. – osgx Apr 05 '10 at 21:09
  • @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 Apr 05 '10 at 21:24
  • 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 Apr 05 '10 at 21:45
  • @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 Apr 05 '10 at 21:50
  • 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 Apr 05 '10 at 21:56
-4

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
  • 12,418
  • 6
  • 43
  • 61
  • it will Not be released only the symbol retStr wouldn't be available – sud03r Apr 05 '10 at 18:03
  • 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 Apr 05 '10 at 18:04
  • @all: my mistake, i was thinking about `retStr`. Will change the answer. – N 1.1 Apr 05 '10 at 18:08