[comp.lang.c] Returning pointers to constant strings

weave@brahms.udel.edu (Ken Weaverling) (05/06/91)

I have scanned the FAQs and have also discussed this topic in a local group,
but would now like to get a few more opinions.

Question: Is there anything dangerous with returning pointers to literal
strings? Is there a portability issue to consider? Is it just bad practice?

Sample code:

char *phredd () {

   char *phrogg;

   phrogg = "Phredd Phrogg's Phantasy Philm";

   return phrogg;
}

 *Solutions* to this are many, such as returning a pointer to a static char
 array, making the literal a global, strdup()'ing it, or strcpy()'ing it
 to another place.  I am concerned with the mentioned issue though.

In the local newsgroup at Univ of Del, the consensus was that it would be
a bad idea, due to systems such as Mess/DOS that might use code overlays,
and the constant string might be stored in a code overlay that would not
always be resident.

I used gdb against a gcc compiled source to verify that the string was 
stored in the code segment just after a function (but not necessarily
the same function that it is used in). I know that it is not a good idea
to alter the string, but that also is not the issue.

Well, I referred to the *bible* for C, the Kernighan and Ritchie book on C,
second edition (for ANSI C).  It says on page 194, section A2.6 ...

A string literal, also called a string constant, is a sequence of characters
surrounded by double quotes, as in "...". A string has type "array of
characters" and storage class *static*.  Whether identical strings are
distinct is implementation-defined, and the behavior of a program that
attempts to alter a string literal is undefined.

.... and then the definition of static from section A4.1 ...

Static objects may be local to a block or external to all blocks, but in
either case, retain their values across exit from and reentry to functions
and blocks.

So, from above, I infer that there is nothing wrong with the code above.
Any comments? Is it still bad practice from a style standpoint? Thanks!

-- 
>>>---> Ken Weaverling  >>>---->  weave@brahms.udel.edu

phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/07/91)

weave@brahms.udel.edu (Ken Weaverling) writes:

>In the local newsgroup at Univ of Del, the consensus was that it would be
>a bad idea, due to systems such as Mess/DOS that might use code overlays,
>and the constant string might be stored in a code overlay that would not
>always be resident.

...

>Well, I referred to the *bible* for C, the Kernighan and Ritchie book on C,
>second edition (for ANSI C).  It says on page 194, section A2.6 ...

>A string literal, also called a string constant, is a sequence of characters
>surrounded by double quotes, as in "...". A string has type "array of
>characters" and storage class *static*.  Whether identical strings are
>distinct is implementation-defined, and the behavior of a program that
>attempts to alter a string literal is undefined.

>.... and then the definition of static from section A4.1 ...

>Static objects may be local to a block or external to all blocks, but in
>either case, retain their values across exit from and reentry to functions
>and blocks.

>So, from above, I infer that there is nothing wrong with the code above.
>Any comments? Is it still bad practice from a style standpoint? Thanks!

I personally would infer that the Mess/DOS code overlays are broken unless
the implementation ensures that somehow the string constant values are not
actually part of the overlaying.

Does the code and the static data of a block have to be continguous in
memory?
-- 
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/

torek@elf.ee.lbl.gov (Chris Torek) (05/09/91)

In article <21139@brahms.udel.edu> weave@brahms.udel.edu (Ken Weaverling)
writes:
>Question: Is there anything dangerous with returning pointers to literal
>strings? Is there a portability issue to consider?

Not really.  The only thing even slightly unusual about this is that
while the type of a string literal is `array N of char' (where N is
one more than the number of characters in the string), the array itself
may, but need not, be placed in read-only (`const') memory.

Thus, the difference between:

	char *f(void) { return "hello"; }

and

	char *f(void) { static char r[] = "hello"; return r; }

is that

	strcpy(f(), "world");

has a well-defined meaning only with the second f().

>Is it just bad practice?

As with anything even vaguely stylistic, different people will hold
different opinions.  For whatever it is worth, I believe this is fine;
you merely must note that the resulting string should not be replaced
as in the strcpy() example above.

>In the local newsgroup at Univ of Del, the consensus was that it would be
>a bad idea, due to systems such as Mess/DOS that might use code overlays,
>and the constant string might be stored in a code overlay that would not
>always be resident.

The local newsgroup is wrong in claiming that overlay systems would be
permitted to do this, but may be right if it claims that some existing,
broken implementation does.  If you want to run on every broken
implementation, you have quite a tough job (you will probably have to
use only the type `int' and only static variables and no more than
three functions and no more than fifty lines of code and ... :-) ).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov