468,786 Members | 1,753 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,786 developers. It's quick & easy.

freeing string literals?

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?


Nov 26 '05 #1
6 2299
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.
Nov 26 '05 #2
"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.
Nov 26 '05 #3
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 ---
Nov 26 '05 #4
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.
Nov 26 '05 #5
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.
Nov 27 '05 #6
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.

Nov 28 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Don Starr | last post: by
7 posts views Thread by al | last post: by
17 posts views Thread by Janice | last post: by
8 posts views Thread by junky_fellow | last post: by
5 posts views Thread by Amogh | last post: by
8 posts views Thread by arnuld | last post: by
4 posts views Thread by =?ISO-8859-15?Q?Jean=2DFran=E7ois?= Lemaire | last post: by
5 posts views Thread by polas | last post: by
7 posts views Thread by lithiumcat | last post: by
reply views Thread by zhoujie | last post: by
2 posts views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.