Is how to lay out the constant string compiler dependent?

[Quentin Yuan]

I always consider that the constant character strings of which
literal value are the same lay out at the same logic address, in
another words, every constant character string have only one copy in
the program. My view base on that if it doesn't that, you lose the
memory of the string that you have used except store the address in a
pointer, this is a form of memory leak although it doesn't really eat
the memory as the general memory leak. The x86 machine always support
my view:-)
But recently someone told me that the addresses of the same character
strings are not the same in SunOS, so it seems that how to lay out the
constant strings is complier dependent. If it's true, I wonder the
reason why my view is wrong? Both informations and links are
appreciated. Thanks to all!

Best Regards

[Chris Dollin]

Quentin Yuan wrote:

I always consider that the constant character strings of which
literal value are the same lay out at the same logic address, in
another words, every constant character string have only one copy in
the program. My view base on that if it doesn't that, you lose the
memory of the string that you have used except store the address in a
pointer, this is a form of memory leak although it doesn't really eat
the memory as the general memory leak. The x86 machine always support
my view:-)
But recently someone told me that the addresses of the same character
strings are not the same in SunOS, so it seems that how to lay out the
constant strings is complier dependent. If it's true, I wonder the
reason why my view is wrong? Both informations and links are
appreciated. Thanks to all!

A C implementation is allowed, but not required, to collapse identical
string literals (and parts thereof).

While it's /nice/ to be able to save space this way, it does require
a certain amount of sophistication in the implementation -- the linker
(or its equivalent) must be able to identify the equal areas /and know
that it can collapse them/. Some linkers don't have the language to be
told that.

It would not surprise me if an implementation shared literals in the
same compilation unit even if it couldn't do so across units.

--
"Possibly you're not recalling some of his previous plans." Zoe, /Firefly/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Eric Sosman]

Chris Dollin wrote:

Quentin Yuan wrote:

> I always consider that the constant character strings of which
literal value are the same lay out at the same logic address, in
another words, every constant character string have only one copy in
the program. My view base on that if it doesn't that, you lose the
memory of the string that you have used except store the address in a
pointer, this is a form of memory leak although it doesn't really eat
the memory as the general memory leak. The x86 machine always support
my view:-)
But recently someone told me that the addresses of the same character
strings are not the same in SunOS, so it seems that how to lay out the
constant strings is complier dependent. If it's true, I wonder the
reason why my view is wrong? Both informations and links are
appreciated. Thanks to all!

A C implementation is allowed, but not required, to collapse identical
string literals (and parts thereof).

While it's /nice/ to be able to save space this way, it does require
a certain amount of sophistication in the implementation -- the linker
(or its equivalent) must be able to identify the equal areas /and know
that it can collapse them/. Some linkers don't have the language to be
told that.

It would not surprise me if an implementation shared literals in the
same compilation unit even if it couldn't do so across units.

Also, some implementations choose to make string literals'
arrays writeable in support of old and now-disparaged API's like
mktemp().[*] Clearly, a literal array that is modifiable cannot
be combined with other supposedly-identical arrays, because the
similarity of their content may be temporary.
[*] Yes, I'm aware that it is possible to use mktemp() in
a way that doesn't rely on modifying literal arrays. But the
bald fact is that existing code frequently applies mktemp() to
a literal -- and what's the implementor to do, get involved in
a blame game with the broken code? The old rhyme about the
driver who "died defending his right of way" comes to mind.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Richard Heathfield]

Eric Sosman said:

<snip>

[*] Yes, I'm aware that it is possible to use mktemp() in
a way that doesn't rely on modifying literal arrays. But the
bald fact is that existing code frequently applies mktemp() to
a literal -- and what's the implementor to do, get involved in
a blame game with the broken code? The old rhyme about the
driver who "died defending his right of way" comes to mind.

Various versions exist. One rendition goes like this:

Here lie the bones of Solomon Gray,
Who died defending his right of way.
He was right, dead right, as he sped along,
But just as dead as if he'd been wrong.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Eric Sosman]

Richard Heathfield wrote:

Eric Sosman said:

<snip>

>[*] Yes, I'm aware that it is possible to use mktemp() in
a way that doesn't rely on modifying literal arrays. But the
bald fact is that existing code frequently applies mktemp() to
a literal -- and what's the implementor to do, get involved in
a blame game with the broken code? The old rhyme about the
driver who "died defending his right of way" comes to mind.

Various versions exist. One rendition goes like this:

Here lie the bones of Solomon Gray,
Who died defending his right of way.
He was right, dead right, as he sped along,
But just as dead as if he'd been wrong.

A search on "defending his right of way" turns up Justin Gray,
old John Gray, Solomon Gray, John O'Day, Captain Grey, Sammy Jay,
Daniel Day (with a rather different closing couplet), Mike O'Day,
William Jay, Mike O'Dea, Paddy O'Shea, John Day (sloppy scansion),
Stubborn O'Day (still sloppier scansion), Justin Grey, Captain Oday,
old John Jay, Johnathan Gray, Roger O'Day, and enough others to
diminish desire for dactyls.

Lurching, nay, reeling towards topicality: The bewildering
assortment of competing variants, each with its supporters, is
reminiscent of the situation confronting the writers of the
original ANSI C Standard.

--
Eric Sosman
es*****@acm-dot-org.invalid