freeing string literals?

[copx]

Can you / are you supposed to free() string literals which are no longer
needed?

In my case I've menu construction code that looks like this:

menu_items = list_new();
list_add(menu_items, "Item 1");
list_add(menu_items, "Item 2");
list_add(menu_items, "Item 3");
menu_create(menu_items, false)

The boolean argument of menu_create() determines whether or not the entries
of the menu_items list (a generic linked-list) are free()ed on destruction.

AFAIK string literals decay into char pointers but aren't supposed to be
free()ed, however I'm not sure.
IIRC string literals remain in memory until program termination.
In my current project I've lots of string literals which are only
temporarily needed and I'm afraid of wasting lots of RAM...
Any ideas?

[Skarmander]

copx wrote:

Can you / are you supposed to free() string literals which are no longer
needed?
No, and no.
In my case I've menu construction code that looks like this:

menu_items = list_new();
list_add(menu_items, "Item 1");
list_add(menu_items, "Item 2");
list_add(menu_items, "Item 3");
menu_create(menu_items, false)

The boolean argument of menu_create() determines whether or not the entries
of the menu_items list (a generic linked-list) are free()ed on destruction.

AFAIK string literals decay into char pointers but aren't supposed to be
free()ed, however I'm not sure.
Right. The general rule is: never free() memory that wasn't malloc()ed
or calloc()ed. Some functions may implicitly allocate memory for you,
but they're rare. String literals are never "allocated" in this way.
IIRC string literals remain in memory until program termination.
In my current project I've lots of string literals which are only
temporarily needed and I'm afraid of wasting lots of RAM...
Any ideas?

Well, that's obvious, innit? Allocate them dynamically and free them
when you don't need them anymore, or use a more advanced string library
with garbage collection.

Before you do this, however, check that you're actually right. Through
the miracle of virtual memory, string literals are often stored as data
that can be paged in on demand from the executable file itself as
necessary and automagically discarded from main memory when space gets
tight. This is unlikely to be a huge drain on system resources, though
it may make for some awkward loading times and a big virtual footprint
(but no increase in actually allocated virtual memory, if the on-demand
paging of readonly data works).

Allocating strings dynamically has fringe benefits, though. Dynamically
loading them has the advantage of allowing internationalization --
something that's hardly feasible with hard-coded string literals. Many
toolkits/frameworks have some form of resource management for this.

Moreover, the "menu creation" scheme you're employing is often handled
by resource files as well, because having to change the code when you
change the menu layout is a maintenance hurt.

S.

[Malcolm]

"copx" <in*****@invalid.com> wrote

AFAIK string literals decay into char pointers but aren't supposed to be
free()ed, however I'm not sure.
string literals are really a little convenience put into the C language.
Declaring one is the same as declaring an array of chars with a terminating
NUL.
You don't need to free arrays created in automatic or static memory, only
arrays created dynamically (with a call to malloc and family).
IIRC string literals remain in memory until program termination.
In my current project I've lots of string literals which are only
temporarily needed and I'm afraid of wasting lots of RAM...
Any ideas?

Somehow you need to get the character information into the computer.
However you could store all your strings in a file and read them in using
fgets(), discarding the buffer when you have done with the string.
Or you could devise some compression scheme where the strings are stored as
an array of unsigned chars (compressed data) and decompressed on the fly.
However add up your memory first. 1 MB is over 100,000 words of English,
about the same as an average novel.

[Joe Wright]

copx wrote:

Can you / are you supposed to free() string literals which are no longer
needed?

In my case I've menu construction code that looks like this:

menu_items = list_new();
list_add(menu_items, "Item 1");
list_add(menu_items, "Item 2");
list_add(menu_items, "Item 3");
menu_create(menu_items, false)

The boolean argument of menu_create() determines whether or not the entries
of the menu_items list (a generic linked-list) are free()ed on destruction.

AFAIK string literals decay into char pointers but aren't supposed to be
free()ed, however I'm not sure.
IIRC string literals remain in memory until program termination.
In my current project I've lots of string literals which are only
temporarily needed and I'm afraid of wasting lots of RAM...
Any ideas?

copx. You obviously write better than you read. Go get your C book and
look up 'free()'.

Yes, string literals are part of your executable and remain until
program termination. However much memory these strings take, C doesn't
promise you can do anything but read them. Whether you can write them
are implementation specific and C is out of the picture. You definitely
cannot 'free()' them.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Skarmander <in*****@dontmailme.com> writes:
[...]

Right. The general rule is: never free() memory that wasn't malloc()ed
or calloc()ed.

<QUIBBLE>Or realloc()ed.</QUIBBLE>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Skarmander]

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> writes:
[...]

Right. The general rule is: never free() memory that wasn't malloc()ed
or calloc()ed.

<QUIBBLE>Or realloc()ed.</QUIBBLE>

Right, right... never free() memory that wasn't (m|c|re)alloc()ed... but
it's just not quite as snappy.

S.

[Jordan Abel]

On 2005-11-27, Skarmander <in*****@dontmailme.com> wrote:

Keith Thompson wrote:

Skarmander <in*****@dontmailme.com> writes:
[...]

Right. The general rule is: never free() memory that wasn't malloc()ed
or calloc()ed.

<QUIBBLE>Or realloc()ed.</QUIBBLE>

Right, right... never free() memory that wasn't (m|c|re)alloc()ed... but
it's just not quite as snappy.

Or, for that matter, never free() memory that _was_ successfully
realloc()ed, for varying methods of verbification.
S.