memory for string literals

[happy]

If I write say, printf("Hello")
Then, does "Hello" is stored for throughout the program since it is
statically stored?

And if it does, Then if I write very large string in printf, Is there
enough memory to store that string?

 

[Tim Prince]

If I write say, printf("Hello")
Then, does "Hello" is stored for throughout the program since it is
statically stored?

And if it does, Then if I write very large string in printf, Is there
enough memory to store that string?

In C89 standard, support for strings of at least 509 characters was
required, I suppose implying yes as an answer to your question up to
that limit. C99 increased the limit to 4095.

 

[happy]

In C89 standard, support for strings of at least 509 characters was
required, I suppose implying yes as an answer to your question up to
that limit.  C99 increased the limit to 4095.

So does that mean that if we count all the characters (printf
strings,scanf strings and string literals declared like char
*a="hello"),
it shouldn't be more than 4095?

 

[Seebs]

So does that mean that if we count all the characters (printf
strings,scanf strings and string literals declared like char
*a="hello"),
it shouldn't be more than 4095?

No, it means each INDIVIDUAL STRING.

The total size available to the program is larger, and somewhat variable.
In practice, you're very unlikely to ever hit it.

-s

 

[happy]

No.  4095 per string literal.  

I asked this question in a c community and someone replied that it is
related to virtual addressing.
How it is related to virtual addressing?

 

[Seebs]

I asked this question in a c community and someone replied that it is
related to virtual addressing.
How it is related to virtual addressing?

Good question. I have no idea. I wouldn't think it would be. Maybe the
person who replied that was an idiot.

-s

 

[Ian Collins]

I asked this question in a c community and someone replied that it is
related to virtual addressing.
How it is related to virtual addressing?

It has absolutely nothing to do with virtual addressing.

 

[Antoninus Twink]

I asked this question in a c community and someone replied that it is
related to virtual addressing.
How it is related to virtual addressing?

Firstly, please ignore the trolls in this group. The 4095 figure is
entirely theoretical. In practice on all current real-world compilers,
string literals can be as big as you want - the only limitation is the
amount of memory available to store them.

Unfortunately, there are a group of people who seek to disrupt this
group by treating all questions as if they are about an abstract machine
that they call the "Death Station", which behaves completely differently
to any machine that actually exists. On the "Death Station", you can
only have one string literal and its length can be no more than 4095. No
real machine behaves like this.

What is the connection with virtual addresses?

Well, the kernel provides each process with a virtual address space, and
takes responsibility for mapping this to physical memory. When your C
program has been loaded and starts executing, the operating system
(executable-loader) has kindly set up this address space to look like
this:


highest address
=========
| |
| |
| |
| |
| |
| |
=========
| data |
| +bss |
=========
| text |
=========
address 0

As your program starts generating stack frames and automatic variables,
the stack grows downwards from high to low memory addresses. Meanwhile,
the heap starts growing upwards from above the data segment.

highest address
=========
| stack |
| vv |
| |
| |
| ^^ |
| heap |
=========
| data |
| +bss |
=========
| text |
=========
address 0

Things get more interesting when you add libraries, threads etc. into
the mix, but this is the basic setup.

Now the data (= data + bss) segment, which sits below the stack, is the
relevant part here. In particular, the data area in the data segment
contains your program's global variables that aren't initialized to zero
- this is where your string literals will live!

Typically, there will be separate read only and read/write data areas. A
string literal like "hello" in
if(strcmp(s, "hello") == 0)
can be placed in the read only area, whereas a global character array
like
char s[] = "hello";
has to be read/write under C rules.

The effect of virtual memory is that string literals can be as big as
you want subject to available physical memory - the 4095 figure is just
a red herring.

 

[Flash Gordon]

Firstly, please ignore the trolls in this group.

Good advice, but given by a troll...

The 4095 figure is
entirely theoretical.

This is true, as others indicated whilst giving good advice.

In practice on all current real-world compilers,
string literals can be as big as you want - the only limitation is the
amount of memory available to store them.

This is not always true. Sometimes there are limits on the size of an
individual object which are smaller than the available memory. Sometimes
there are limits on processes which are smaller than the available memory.

Unfortunately, there are a group of people who seek to disrupt this
group by treating all questions as if they are about an abstract machine
that they call the "Death Station", which behaves completely differently
to any machine that actually exists. On the "Death Station", you can
only have one string literal and its length can be no more than 4095. No
real machine behaves like this.

This is just a plain and simple lie.

What is the connection with virtual addresses?

Well, the kernel provides each process with a virtual address space, and

- this is where your string literals will live!

All of the stuff snipped may be correct for some specific systems, but
there are a lot where the rules are different, and in any case it is
largely irrelevant unless you are getting in to very low level stuff.

Typically, there will be separate read only and read/write data areas. A
string literal like "hello" in
if(strcmp(s, "hello") == 0)
can be placed in the read only area, whereas a global character array
like
char s[] = "hello";
has to be read/write under C rules.

The above is true.

The effect of virtual memory is that string literals can be as big as
you want subject to available physical memory - the 4095 figure is just
a red herring.

The truth is that it is nothing to do with virtual memory as others
said. The compiler and environment will impose limits, and it might well
be that the compiler would run out of memory on compiling a program with
a stupidly large string literal before you reached a size which would
cause the program to run out of memory when run, particularly if the
program is as simple as

#include <stdio.h>

int main(void)
{
puts(STUPIDLY_LARGE_STRING_LITERAL);
return 0;
}

Where STUPIDLY_LARGE_STRING_LITERAL is replaced by a large enough string
literal.

All of this is still true on machines *without* virtual memory, hence
this troll is wrong when he says it is to do with virtual memory.

 

[jacob navia]

Antoninus Twink a écrit :

Firstly, please ignore the trolls in this group. The 4095 figure is
entirely theoretical. In practice on all current real-world compilers,
string literals can be as big as you want - the only limitation is the
amount of memory available to store them.

I think you are right Antoninus, but (maybe) it is worth mentioning that the C99
standard mentions 4095 bytes as the minimum REQUIRED length of string literals.
I quote from 5.2.4.1 "Translation limits":

The implementation shall be able to translate and execute at least one program that
contains at least one instance of every one of the following limits
[snip]
4095 characters in a character string literal or wide string literal (after concatenation)

This means that all C implementations MUST support at least 4095 bytes for a single string

 

[Tim Prince]

I asked this question in a c community and someone replied that it is
related to virtual addressing.
How it is related to virtual addressing?

Did someone misquote? The original limit may be related to addressing
modes used on some machine in the distant past. The 509 character per
string limit of C89 looks like an IBM360 sort of limitation.

 

[robertwessel2]

Firstly, please ignore the trolls in this group. The 4095 figure is
entirely theoretical. In practice on all current real-world compilers,
string literals can be as big as you want - the only limitation is the
amount of memory available to store them.

To clarify, many compilers have limits on the size of a single string
literal, while allowing many to be defined and the total size of the
string literal pool to be a large fraction of the available space.
For example, MSVC allows 65535 byte string literals, after
concatenation of adjacent string literals (individual string literals
can be up to 2048 bytes). Although you can store many of those.

 

[David Thompson]

Did someone misquote? The original limit may be related to addressing
modes used on some machine in the distant past. The 509 character per
string limit of C89 looks like an IBM360 sort of limitation.

The S/360 limitation (MVC etc.) would be 255.

512 was the PDP-11 disk sector size and (thus) early Unix filesystem
block size. For I/O-ly things like output-per-conversion-specifier
and maybe sourceline-size 509 would make sense as 512-slop;
but BUFSIZ can be 256 and textfile linesize 254 = 256-slop.

And a string literal _before_ concatenation is standardly limited by
sourcefile linesize. But since a main point of concatentation is to
relax that limit, I would expect it not to apply _after_.