free or not pointer to char returned

A

Antoine Junod

Hi,

Some functions, for example ctime of time.h, return a pointer to
char. Is it my job to free it or not? How could I know if it's a chunk
of memory allocated with malloc or a tab?

Thanks for your reply,
-AJ
 
K

Keith Thompson

Antoine Junod said:
Some functions, for example ctime of time.h, return a pointer to
char. Is it my job to free it or not? How could I know if it's a chunk
of memory allocated with malloc or a tab?

(A "tab"?)

It depends on the function.

In the case of ctime(), it returns the address of a static object.
 
E

Eric Sosman

Antoine said:
array, sorry.


Ok thanks. I didn't read the man page carefully enough :)

The only Standard library functions that require you to
decide when to free allocated memory are malloc(), calloc(),
and realloc(). Other Standard library functions that return
pointers to "library objects" -- fopen(), for example -- take
care of their own memory management, and you must not free
the pointers they return.

For non-Standard functions, read the documentation.
 
C

Christopher Benson-Manica

Antoine Junod said:
Ok thanks. I didn't read the man page carefully enough :)

Just as an aside, man pages alone are not always sufficient to discern
the details concerning function X. Case in point being certain man
pages that editorialize against using strtok(), which can be a
perfectly reasonable tool choice.
 
B

Ben Pfaff

Christopher Benson-Manica said:
> Just as an aside, man pages alone are not always sufficient to discern
> the details concerning function X. Case in point being certain man
> pages that editorialize against using strtok(), which can be a
> perfectly reasonable tool choice.

It can be. But strtok() has at least these problems:

* It merges adjacent delimiters. If you use a comma as your
delimiter, then "a,,b,c" will be divided into three tokens,
not four. This is often the wrong thing to do. In fact, it
is only the right thing to do, in my experience, when the
delimiter set contains white space (for dividing a string
into "words") or it is known in advance that there will be
no adjacent delimiters.

* The identity of the delimiter is lost, because it is
changed to a null terminator.

* It modifies the string that it tokenizes. This is bad
because it forces you to make a copy of the string if
you want to use it later. It also means that you can't
tokenize a string literal with it; this is not
necessarily something you'd want to do all the time but
it is surprising.

* It can only be used once at a time. If a sequence of
strtok() calls is ongoing and another one is started,
the state of the first one is lost. This isn't a
problem for small programs but it is easy to lose track
of such things in hierarchies of nested functions in
large programs. In other words, strtok() breaks
encapsulation.
 
C

Christopher Benson-Manica

Ben Pfaff said:
It can be. But strtok() has at least these problems:
(snip)

Yes, strtok() has more than its share of idiosyncrancies, meaning that
it isn't as widely applicable as it could be. But as Brian Rodenborn
said four years ago (in response to a naive question ultimately posed
by me, incidentally - I'm enough embarrassed by my inexperience at the
time to not want to post the link), "The prohibitions on the use of
strtok() can be somewhat hysterical at times." The lesson to OP is
that when man strtok tells you to "never use this function", it's not
wise to treat it as gospel truth.
 
E

Eric Sosman

CBFalconer wrote On 05/24/07 21:59,:
/* ------- file toksplit.c ----------*/
#include "toksplit.h"
[...]
A better name would be "strtkn", except that is reserved
for the system namespace. Change to that at your risk.
[...]
const char *toksplit(const char *src, /* Source of tokens */
char tokchar, /* token delimiting char */
char *token, /* receiver of parsed token */
size_t lgh) /* length token can receive */
/* not including final '\0' */

Um, er, out of frying pan and into fire. `toksplit'
with external linkage is a reserved identifier (7.26.2).

I suggest renaming the function to `noalias' ;-)
 
K

Keith Thompson

Eric Sosman said:
Um, er, out of frying pan and into fire. `toksplit'
with external linkage is a reserved identifier (7.26.2).

I suggest renaming the function to `noalias' ;-)

That joke must go. This is non-negotiable.
 
H

Harald van =?UTF-8?B?RMSzaw==?=

CBFalconer said:
Eric said:
CBFalconer wrote On 05/24/07 21:59,:
/* ------- file toksplit.c ----------*/
#include "toksplit.h"
[...]
A better name would be "strtkn", except that is reserved
for the system namespace. Change to that at your risk.
[...]
const char *toksplit(const char *src, /* Source of tokens */
char tokchar, /* token delimiting char */
char *token, /* receiver of parsed token */
size_t lgh) /* length token can receive */
/* not including final '\0' */

Um, er, out of frying pan and into fire. `toksplit'
with external linkage is a reserved identifier (7.26.2).

I suggest renaming the function to `noalias' ;-)

I see no such restricion in N869. Can you be more explicit?

"to" followed by a lowercase letter means toksplit is technically reserved
for current implementations and future standards as a function declared in
<ctype.h> (see 7.26.2).
 
G

Giorgos Keramidas

Chris said:
CBFalconer said:
Harald van D?k wrote:
"to" followed by a lowercase letter means toksplit is technically
reserved for current implementations and future standards as a
function declared in <ctype.h> (see 7.26.2).

Ulp. Time to rename to "tknsplit".

Or `splitToken` [or `split_token`, depending on rainfall].

I hate underscores. They require finding a key, and a shift!

But but, they look so "niiiiiiice!" (Borat mode) :)
 
E

Eric Sosman

CBFalconer wrote On 05/25/07 12:09,:
Eric said:
CBFalconer wrote On 05/24/07 21:59,:

/* ------- file toksplit.c ----------*/
#include "toksplit.h"
[...]
A better name would be "strtkn", except that is reserved
for the system namespace. Change to that at your risk.
[...]
const char *toksplit(const char *src, /* Source of tokens */
char tokchar, /* token delimiting char */
char *token, /* receiver of parsed token */
size_t lgh) /* length token can receive */
/* not including final '\0' */

Um, er, out of frying pan and into fire. `toksplit'
with external linkage is a reserved identifier (7.26.2).

I suggest renaming the function to `noalias' ;-)


I see no such restricion in N869. Can you be more explicit?

WG14/N869:

7.26 Future library directions
1) [...] All external names described below are
reserved no matter what headers are included
by the program.


7.26.2 Character handling <ctype.h>
1) Function names that begin with either *is* or *to*,
and a lowercase letter (possibly followed by any
combination of digits, letters, and underscore) may
be added to the declarations in the <ctype.h> header.

7.1.2 Standard headers
6) Any declaration of a library function shall
have external linkage.

ISO/IEC 9899:TC2 omits the parenthesized piece of 7.26.2,
but is otherwise the same.
 
C

Charles Richmond

CBFalconer said:
Chris said:
CBFalconer said:
Harald van D?k wrote:
"to" followed by a lowercase letter means toksplit is technically
reserved for current implementations and future standards as a
function declared in <ctype.h> (see 7.26.2).
Ulp. Time to rename to "tknsplit".
Or `splitToken` [or `split_token`, depending on rainfall].

I hate underscores. They require finding a key, and a shift!

But underscores in the middle of a variable name as a
break character... makes the name much easier to read.
It's like other types of documentation: perhaps a pain
to write but a great aid to reading and understanding
the program code.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top