free or not pointer to char returned

Discussion in 'C Programming' started by Antoine Junod, May 24, 2007.

  1. 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
     
    Antoine Junod, May 24, 2007
    #1
    1. Advertising

  2. Antoine Junod <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 24, 2007
    #2
    1. Advertising

  3. Keith Thompson <> writes:

    > Antoine Junod <> writes:
    > > 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"?)


    array, sorry.

    > It depends on the function.
    >
    > In the case of ctime(), it returns the address of a static object.


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

    -AJ
     
    Antoine Junod, May 24, 2007
    #3
  4. Antoine Junod

    Eric Sosman Guest

    Antoine Junod wrote:
    > Keith Thompson <> writes:
    >
    >> Antoine Junod <> writes:
    >>> 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"?)

    >
    > array, sorry.
    >
    >> It depends on the function.
    >>
    >> In the case of ctime(), it returns the address of a static object.

    >
    > 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.

    --
    Eric Sosman
    lid
     
    Eric Sosman, May 24, 2007
    #4
  5. Antoine Junod <> wrote:

    > 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.

    --
    C. Benson Manica | I *should* know what I'm talking about - if I
    cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, May 24, 2007
    #5
  6. Antoine Junod

    Ben Pfaff Guest

    Christopher Benson-Manica <> writes:

    > 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.

    --
    Comp-sci PhD expected before end of 2007
    Seeking industrial or academic position *outside California* in 2008
     
    Ben Pfaff, May 24, 2007
    #6
  7. Ben Pfaff <> wrote:

    > 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.

    --
    C. Benson Manica | I *should* know what I'm talking about - if I
    cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, May 24, 2007
    #7
  8. Antoine Junod

    Eric Sosman Guest

    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' ;-)

    --
     
    Eric Sosman, May 25, 2007
    #8
  9. Eric Sosman <> writes:
    [...]
    > 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.

    --
    Keith Thompson (The_Other_Keith) <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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 25, 2007
    #9
  10. CBFalconer wrote:
    > Eric Sosman wrote:
    >> 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).
     
    Harald van =?UTF-8?B?RMSzaw==?=, May 26, 2007
    #10
  11. Antoine Junod

    Chris Dollin Guest

    CBFalconer wrote:

    > 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].

    --
    More Rain Here Hedgehog
    "No-one here is exactly what he appears." G'kar, /Babylon 5/
     
    Chris Dollin, May 27, 2007
    #11
  12. On Sun, 27 May 2007 09:05:09 -0400, CBFalconer <> wrote:
    >Chris Dollin wrote:
    >>CBFalconer wrote:
    >>>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) :)
     
    Giorgos Keramidas, May 28, 2007
    #12
  13. Antoine Junod

    Eric Sosman Guest

    CBFalconer wrote On 05/25/07 12:09,:
    > Eric Sosman wrote:
    >
    >>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.

    --
     
    Eric Sosman, May 29, 2007
    #13
  14. CBFalconer wrote:
    > Chris Dollin wrote:
    >> CBFalconer wrote:
    >>> 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.

    --
    +----------------------------------------------------------------+
    | Charles and Francis Richmond richmond at plano dot net |
    +----------------------------------------------------------------+
     
    Charles Richmond, May 30, 2007
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. wwj
    Replies:
    7
    Views:
    558
  2. wwj
    Replies:
    24
    Views:
    2,520
    Mike Wahler
    Nov 7, 2003
  3. Ben Pfaff
    Replies:
    5
    Views:
    480
    Tristan Miller
    Jan 17, 2004
  4. lovecreatesbeauty
    Replies:
    1
    Views:
    1,058
    Ian Collins
    May 9, 2006
  5. C++Liliput
    Replies:
    5
    Views:
    896
    Pete Becker
    Dec 12, 2007
Loading...

Share This Page