Allocating memory for strings

[Win Sock]

Hi All,
somebody told me this morning that the following is leagal.

char *a = "Hello wrold";

The memory is automatically allocated on the fly. Is this correct?

[santosh]

Win Sock wrote:

Hi All,
somebody told me this morning that the following is leagal.

char *a = "Hello wrold";

The memory is automatically allocated on the fly. Is this correct?

The storage for the string is set aside during translation and the
pointer 'a' is set to point to it's beginning.

If the pointer is not static and no other pointers point to the string,
then the string becomes irretrievable when 'a' goes out of scope.

[christian.bau]

On Oct 6, 6:45 pm, Win Sock <nos...@nospam. comwrote:

Hi All,
somebody told me this morning that the following is leagal.

char *a = "Hello wrold";

The memory is automatically allocated on the fly. Is this correct?

No.

A string literal like "Hello wrold" works exactly as if you had a
static array of const char, and got a pointer to that array, cast to
char* instead of const char*. So

char *a = "Hello wrold";

works exactly the same as

const char secret_array [] = "Hello wrold";
char *a = (char *) secret_array;

[Joe Wright]

Win Sock wrote:

Hi All,
somebody told me this morning that the following is leagal.

char *a = "Hello wrold";

The memory is automatically allocated on the fly. Is this correct?

Not in the sense of malloc() and friends. free(a) is Undefined. The
constant string "Hello wrold" is placed somewhere in memory as an
anonymous array of char, the address of which is placed in a.

Spelling? legal and world.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Ben Pfaff]

"christian. bau" <ch***********@ cbau.wanadoo.co .ukwrites:

char *a = "Hello wrold";

works exactly the same as

const char secret_array [] = "Hello wrold";
char *a = (char *) secret_array;

If it's outside any function, yet; otherwise, secret_array must
be declared static.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt

[Keith Thompson]

"christian. bau" <ch***********@ cbau.wanadoo.co .ukwrites:

On Oct 6, 6:45 pm, Win Sock <nos...@nospam. comwrote:

>somebody told me this morning that the following is leagal.

char *a = "Hello wrold";

The memory is automatically allocated on the fly. Is this correct?

No.

A string literal like "Hello wrold" works exactly as if you had a
static array of const char, and got a pointer to that array, cast to
char* instead of const char*. So

char *a = "Hello wrold";

works exactly the same as

const char secret_array [] = "Hello wrold";
char *a = (char *) secret_array;

Except that string literals aren't const. (Attempting to modify a
string literal invokes undefined behavior, but only because the
standard explicitly says so.) It would be better if string literals
*were* const, but that would have broken existing code back in 1989
when the ANSI standard first introduced the "const" keyword.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Tor Rustad]

Win Sock wrote:

Hi All,
somebody told me this morning that the following is leagal.

char *a = "Hello wrold";

The memory is automatically allocated on the fly. Is this correct?

String literals may be placed in read-only memory, and it's undefined
behavior (UB) altering what *a points to. Hence, you should rather use:

const char *a = "Hello wrold";

Note that, else the compiler might not catch this error:

$ cat -n main.c
1 #include <stdio.h>
2
3
4 int main(void)
5 {
6 char *a = "Hello";
7 const char *b = "Hello";
8
9 printf("%s %s\n", a, b);
10
11 a[0]='\0';
12 b[0]='\0';
13
14 return 0;
15 }

$ gcc -ansi -pedantic -W -Wall main.c
main.c: In function âmainâ:
main.c:12: error: assignment of read-only location

above, there was no warning about the UB at line 11!

--
Tor <torust [at] online [dot] no>

"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies"

[santosh]

Tor Rustad wrote:

Win Sock wrote:

>Hi All,
somebody told me this morning that the following is leagal.

char *a = "Hello wrold";

The memory is automatically allocated on the fly. Is this correct?

String literals may be placed in read-only memory, and it's undefined
behavior (UB) altering what *a points to. Hence, you should rather
use:

const char *a = "Hello wrold";

Note that, else the compiler might not catch this error:

$ cat -n main.c
1 #include <stdio.h>
2
3
4 int main(void)
5 {
6 char *a = "Hello";
7 const char *b = "Hello";
8
9 printf("%s %s\n", a, b);
10
11 a[0]='\0';
12 b[0]='\0';
13
14 return 0;
15 }

$ gcc -ansi -pedantic -W -Wall main.c
main.c: In function âmainâ:
main.c:12: error: assignment of read-only location

above, there was no warning about the UB at line 11!

Interestingly if the const qualifier is removed, compilation succeeds
under gcc, but the executable terminates with a segmentation fault.
This indicates that gcc places the strings in read-only storage.

On the other hand under the lcc-linux32 compiler nothing unexpected
happens. Apparently string literals are _not_ placed into read-only
storage by lcc-linux32.

[Ben Pfaff]

Keith Thompson <ks***@mib.orgw rites:

"christian. bau" <ch***********@ cbau.wanadoo.co .ukwrites:

> char *a = "Hello wrold";

works exactly the same as

const char secret_array [] = "Hello wrold";
char *a = (char *) secret_array;

Except that string literals aren't const. (Attempting to modify a
string literal invokes undefined behavior, but only because the
standard explicitly says so.)

I think that's why Christian included the cast to char *. With
the cast, the effect is the same.
--
char a[]="\n .CJacehknorstu" ;int putchar(int);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,0x11f6} ,*p
=b,i=24;for(;p+ =!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Tor Rustad]

santosh wrote:

[...]

Interestingly if the const qualifier is removed, compilation succeeds
under gcc, but the executable terminates with a segmentation fault.
This indicates that gcc places the strings in read-only storage.

Yes.

On the other hand under the lcc-linux32 compiler nothing unexpected
happens. Apparently string literals are _not_ placed into read-only
storage by lcc-linux32.

Did you get a warning with lcc-linux32? I don't have the lcc-linux32
compiler, but it could use the same storage location for those two
string literals, which I purpose used "Hello" for both.

So something "unexpected " could still happen.

Note that splint issue two warnings for the sample code i posted.

--
Tor <torust [at] online [dot] no>

"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies"