[comp.lang.c] String assignments; Was: When is a cast not a cast?

rds95@leah.Albany.Edu (Robert Seals) (05/02/89)

> In article <2747@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
> [some stuff about pointers which has been conquered with aplomb by
> Bill Davidson et al...but the stuff that gets me is...]
>
> | 3	char *c;
> ...
> | 7	c = "somestring";  /* Nothing fancy, null-terminated. */

Now I always thought this kind of thing was extremely bad form, but
I've recently seen a couple of code examples that use this. 
One figures that if ``somestring'' is generated by the compiler somewhere,
then the assignment will work as expected, because the address of it will
be copied to ``c''. But what if the compiler decides that ``somestring''
has finished it's duty to the program, and overwrites the space it took
with something else? Then ``c'' points to rubbish. Right?

I've always used stuff like ``char *c = "string";'' which the compiler
should know how to deal with, as it's an initializer, or something along
the lines of
	char *c;
	c = (char *) malloc(something);
	strcpy(c, somethingelse);

Have I been misguided all this time?

rob

roemer@cs.vu.nl (Roemer Lievaart) (05/03/89)

rds95@leah.Albany.Edu (Robert Seals) writes:

>Right?
Wrong.

>Have I been misguided all this time?
Yes.

chris@mimsy.UUCP (Chris Torek) (05/03/89)

[char *c = "somestring";]

In article <1814@leah.Albany.Edu> rds95@leah.Albany.Edu (Robert Seals) writes:
>Now I always thought this kind of thing was extremely bad form, but
>I've recently seen a couple of code examples that use this. 
>One figures that if ``somestring'' is generated by the compiler somewhere,
>then the assignment will work as expected, because the address of it will
>be copied to ``c''.

This is correct.  The array-11-of-char

	{'s', 'o', 'm', 'e', 's', 't', 'r', 'i', 'n', 'g', '\0'}

is generated (somewhere, somehow) by the compiler; the value of the 
double-quoted expression is thus an object of type

	char [11]

which in this context is immediately converted to one of type

	char *

whose value is the address of the first `s' (wherever the compiler
has placed it).

>But what if the compiler decides that ``somestring'' has finished its
>duty to the program, and overwrites the space it took with something
>else?

Then the compiler has a bug.

Objects created with "foo" have type array-N-of-char and storage class
*static* (and no name, hence no scope class).  They must be created by
the time the runtime system calls main() and live unchanged (unless
overwritten by programmer error) until the program exits.

It is possible for the *programmer* to (attempt to) overwrite the space
with something else:

	strcpy("here is some static string space", "but this is a bad idea");

In particular, this is allowed to fail (with `segmentation fault - core
dumped' or the like) at runtime.  Traditionally, Unix C compilers have
placed these strings in a read/write data area along with other
initialised global and static variables, but newer compilers (gcc) put
them in the text segment instead.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

mat@mole-end.UUCP (Mark A Terribile) (05/04/89)

> > | 7	c = "somestring";  /* Nothing fancy, null-terminated. */
 
> Now I always thought this kind of thing was extremely bad form, ... But what
> if the compiler decides that ``somestring'' has finished its duty to the
> program, and overwrites the space it took with something else? ...

> Have I been misguided all this time?


Both K&R-I and K&R-II, in the appendices, under the heading ``String
Constants'', declare that a string has the storage class  static , which
means that the lifetime of the object is the lifetime of the program.

-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile