On Thu, 22 Apr 1999, Chris Faherty wrote:
> I just used pilot-file to look at my PRC file and I realized that GCC puts
> literal constants into the code resource. Such that a line like this will
> take up code space for the literal string:
>
> ShowErrorMsg("missing required rfc822 fields.");
>
> Whereas this will not:
>
> char message[]="missing required rfc822 fields.";
> ShowErrorMsg(message);
>
> Is this normal?
Yes. These mean two different things. If you create literal strings in
this manner:
char * foo = "string";
bar("string");
baz = 3 + "string";
then all those "string"'s will be in the code segment (assuming the
compiler wants to, is capable, and hasn't been instructed otherwise). The
compiler is normally allowed to assume that these strings will not be
modified, so it can put them in the (read-only) code segment, and can also
combine them. (I.e., all the above instances of "string" may refer to the
same place in the code segment).
On the other hand, if you say:
char bletch[] = "string";
then you are using a special initializer syntax that says: give me an
array long enough to contain this data, and initialize it with that data.
Thus bletch[] is a writable character array seven bytes long (six
characters plus NULL), and has "string" copied into it at program load.
> And I suppose I should get rid of all of my literals and make them into
> globals so that I won't run out of 32K code space. But then won't the
> globals eat into my ~60K dynamic heap?
Yes, and dynamic heap can be as low as 12K on older machines. The original
"string" is now taking up memory in two places: the heap, and the .data
segment of your program code.
But I'm not sure what particular strategy GCC uses for placing literals:
they may be only at the end of the code segment, in which case they can
extend past the first 32K easily. (Which isn't precisely a hard limit, or
at least it doesn't have to be.)
> What is the best way to store strings like that?
Logically, since the string _has_ to be in your program code, put it in
the code segment so that it won't _also_ take up RAM. If you've got a lot
of strings, you might consider storing them as separate resources.
--
Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
