🚀 go-pugleaf

I've never been completely clear about how ANSI-C (and, hence, Objective-C)
stores string constants.  I'm sure the amount of memory consumed by strings in
the typical NeXT app is a mere drop in the bucket, but I'm still curious about
the "proper" way to allocate string constants.

const char *aStringPtr = "string";
const char aString[] = "string";

I've assumed that the memory referenced by aStringPtr is in some read-only heap
area.  When aStringPtr is no longer needed, can this memory be freed with
free(aStringPtr)?

I've assumed that aString is a character array that's allocated on the stack if
aString is a local variable, so its memory is freed once the block in which
it's defined is exited.

But where do NXUniqueString() and NXUniqueStringNoCopy() fit into this scheme?
If I say

	NXAtom anAtom = NXUniqueString("string");
	NXAtom anotherAtom = NXUniqueStringNoCopy("string");

does "anAtom" point to a hashed copy of "string" so that memory is allocated in
2 different places for "string" whereas "anotherAtom" points to only a hashed
pointer to the heap memory where "string" is found?  Should unique strings be
used only for strings that are repeated throughout an app?  I guess I can avoid
defining a global variable by using

	NXAtom anAtom = NXUniqueString("string");

repeatedly because "string" is already in the unique string hash table, but
won't C allocate additional heap memory for the "string" argument of each
NXUniqueString() call?  If so, I guess another approach would be

	NXAtom anAtom = NXUniqueString(aString);

where "aString" is a local character array.

Pretty dumb, insignificant questions in the universe of NeXTSTEP questions
(probably would fail AFS's test for the programmer FAQ :-), but someone at NeXT
thought that unique strings were worth the effort of writing several functions
to deal with them.  I realize another advantage is quicker string comparisons
using unique strings, but I doubt that defining a pair of unique strings is
more efficient that just comparing them using NXOrderStrings().

Another implication of all this is seen when using MallocDebug.  For instance,
Storage's "free" does not free the type encoding string, so does this show up
as a memory leak in MallocDebug if a string constant is used as the type
encoding string?  So is making the type encoding string a local char array the
proper approach?  Pretty nit picky, but I'd like to eliminate all this
relatively minor cruft in the MallocDebug memory leak output (if it's actually
there - it's been a while since I've used MallocDebug).

Thanks for your comments and clarifications.
-- 

Art Isbell                                                      Cubic Solutions
NeXT Registered Developer #745         NeXT software development and consulting
Email: isbell@cats.UCSC.EDU                                Voice: (408)335-1154
USmail: 95018-9442                                           Fax: (408)335-2515