List of reentrant C library functions

Discussion in 'C Programming' started by TheOne, Nov 28, 2005.

  1. TheOne

    TheOne Guest

    Would anyone please point me to a list of reentrant C library
    functions? I want to know which C library functions are safe to
    use inside a signal handler across all platforms. Does GNU C
    library make few other functions reentrant on Linux platform?

    I have searched a lot on the web for it but without any
    success. Man page of signal(2) has listed system calls (POSIX
    1003.1-2003 list) which are safe(reentrant) but thats not sufficient
    for my purpose.

    Thanks in advance.
    TheOne, Nov 28, 2005
    #1
    1. Advertising

  2. TheOne

    Ben Pfaff Guest

    "TheOne" <> writes:

    > Would anyone please point me to a list of reentrant C library
    > functions? I want to know which C library functions are safe to
    > use inside a signal handler across all platforms.


    The C standard says this:

    4 The functions in the standard library are not guaranteed to be
    reentrant and may modify objects with static storage
    duration.158)

    158) Thus, a signal handler cannot, in general, call
    standard library functions.

    ....

    5 If the signal occurs other than as the result of calling the
    abort or raise function, the behavior is undefined if the
    signal handler refers to any object with static storage
    duration other than by assigning a value to an object
    declared as volatile sig_atomic_t, or the signal handler
    calls any function in the standard library other than the
    abort function, the _Exit function, or the signal function
    with the first argument equal to the signal number
    corresponding to the signal that caused the invocation of
    the handler. Furthermore, if such a call to the signal
    function results in a SIG_ERR return, the value of errno is
    indeterminate.211)

    So, here's your list: abort(), _Exit(), and (with some
    restrictions) signal().

    > Does GNU C library make few other functions reentrant on Linux
    > platform?


    It'd be better to ask about that in a GNU or Linux group.
    --
    Go not to Usenet for counsel, for they will say both no and yes.
    Ben Pfaff, Nov 28, 2005
    #2
    1. Advertising

  3. TheOne

    P.J. Plauger Guest

    "Ben Pfaff" <> wrote in message
    news:...

    > "TheOne" <> writes:
    >
    >> Would anyone please point me to a list of reentrant C library
    >> functions? I want to know which C library functions are safe to
    >> use inside a signal handler across all platforms.

    >
    > The C standard says this:
    >
    > 4 The functions in the standard library are not guaranteed to be
    > reentrant and may modify objects with static storage
    > duration.158)
    >
    > 158) Thus, a signal handler cannot, in general, call
    > standard library functions.
    >
    > ...
    >
    > 5 If the signal occurs other than as the result of calling the
    > abort or raise function, the behavior is undefined if the
    > signal handler refers to any object with static storage
    > duration other than by assigning a value to an object
    > declared as volatile sig_atomic_t, or the signal handler
    > calls any function in the standard library other than the
    > abort function, the _Exit function, or the signal function
    > with the first argument equal to the signal number
    > corresponding to the signal that caused the invocation of
    > the handler. Furthermore, if such a call to the signal
    > function results in a SIG_ERR return, the value of errno is
    > indeterminate.211)
    >
    > So, here's your list: abort(), _Exit(), and (with some
    > restrictions) signal().
    >
    >> Does GNU C library make few other functions reentrant on Linux
    >> platform?

    >
    > It'd be better to ask about that in a GNU or Linux group.


    Indeed.
    P.J. Plauger, Nov 28, 2005
    #3
  4. TheOne

    Flash Gordon Guest

    TheOne wrote:
    > Would anyone please point me to a list of reentrant C library
    > functions?


    Not here, because none of the standard library functions are guaranteed
    to be re-entrant by the standard.

    > I want to know which C library functions are safe to
    > use inside a signal handler across all platforms. Does GNU C
    > library make few other functions reentrant on Linux platform?


    You will have to ask on a Linux or Unix group, such as comp.unix.programmer

    > I have searched a lot on the web for it but without any
    > success. Man page of signal(2) has listed system calls (POSIX
    > 1003.1-2003 list) which are safe(reentrant) but thats not sufficient
    > for my purpose.


    The try a Linux news group, we only deal with standard C.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Nov 28, 2005
    #4
  5. TheOne

    P.J. Plauger Guest

    Let's try again.

    "Ben Pfaff" <> wrote in message
    news:...

    > "TheOne" <> writes:
    >
    >> Would anyone please point me to a list of reentrant C library
    >> functions? I want to know which C library functions are safe to
    >> use inside a signal handler across all platforms.

    >
    > The C standard says this:
    >
    > 4 The functions in the standard library are not guaranteed to be
    > reentrant and may modify objects with static storage
    > duration.158)
    >
    > 158) Thus, a signal handler cannot, in general, call
    > standard library functions.
    >
    > ...
    >
    > 5 If the signal occurs other than as the result of calling the
    > abort or raise function, the behavior is undefined if the
    > signal handler refers to any object with static storage
    > duration other than by assigning a value to an object
    > declared as volatile sig_atomic_t, or the signal handler
    > calls any function in the standard library other than the
    > abort function, the _Exit function, or the signal function
    > with the first argument equal to the signal number
    > corresponding to the signal that caused the invocation of
    > the handler. Furthermore, if such a call to the signal
    > function results in a SIG_ERR return, the value of errno is
    > indeterminate.211)
    >
    > So, here's your list: abort(), _Exit(), and (with some
    > restrictions) signal().
    >
    >> Does GNU C library make few other functions reentrant on Linux
    >> platform?

    >
    > It'd be better to ask about that in a GNU or Linux group.


    Indeed. I think this list is a little short. Attached below is
    the list we supply our customers (on request) of writable static
    data and how we protect it. We use:

    TLS -- thread-local storage

    MALLOC -- thread lock for mallocs (when heap is shared)

    LOCALE -- thread lock for locales (when locales are shared)

    STREAM -- thread lock for each FILE object (when streams are shared)

    UNPROTECTED -- for program termination

    Most of the time the file name suggests the corresponding
    function, so I won't bother to translate.

    HTH,

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com

    -------

    asctime.c -- contains time formatting information that can be changed by
    a call to setlocale, plus the default time string buffer [TLS]

    atexit.c -- contains the stack of functions to call at exit time [MALLOC]

    exit.c -- pops the stack of functions to call at exit time [UNPROTECTED]

    fclose.c -- contains the list of files to close at exit time [UNPROTECTED]

    localeco.c -- contains numeric, monetary, and message information that
    can be changed by a call to setlocale [TLS]

    localtim.c -- contains timezone information that can be changed by a call
    to setlocale [TLS]

    malloc.c -- contains the root of the heap [MALLOC]

    mbrlen.c -- contains a default mbstate_t object [TLS]

    mbrtowc.c -- contains a default mbstate_t object [TLS]

    mbsrtowc.c -- contains a default mbstate_t object [TLS]

    mbtowc.c -- contains a default mbstate_t object [TLS]

    rand.c -- contains the seed for random numbers [TLS]

    setlocal.c -- contains current locale information that can be changed by
    a call to setlocale [TLS]

    signal.c -- contains a table of signal handlers that can be changed by
    a call to signal [MALLOC]

    strtok.c -- contains a pointer to the string currently being parsed [TLS]

    tmpnam.c -- contains the current temporary file name [MALLOC]

    wcrtomb.c -- contains a default mbstate_t object [TLS]

    wcsrtomb.c -- contains a default mbstate_t object [TLS]

    wctomb.c -- contains a default mbstate_t object [TLS]

    xfiles.c -- contains the FILE objects [fclose/fflush/fopen STREAM]

    xgetloc.c -- contains locale information that can be changed by
    a call to setlocale [LOCALE]

    xgetzone.c -- contains timezone information that can be changed by
    a call to setlocale [LOCALE]

    xisdst.c -- contains timezone information that can be changed by
    a call to setlocale [TLS]

    xstrerro.c -- contains the default buffer used by strerror [TLS]

    xctype.c -- contains ctype information that can be changed by
    a call to setlocale [TLS]

    xdefloc.c -- contains default locale information that can be changed by
    a call to setlocale [LOCALE]

    xlocterm.c -- contains locale parsing information that can be changed
    by a call to setlocale [TLS]

    xstate.c -- contains ctype information that can be changed by
    a call to setlocale [TLS]

    xtolotab.c -- contains ctype information that can be changed by
    a call to setlocale [TLS]

    xtouptab.c -- contains ctype information that can be changed by
    a call to setlocale [TLS]

    xttotm.c -- contains default tm structure used by gmtime and localtime [TLS]

    xwctrtab.c -- contains ctype information that can be changed by
    a call to setlocale [TLS]

    xwctytab.c -- contains ctype information that can be changed by
    a call to setlocale [TLS]
    P.J. Plauger, Nov 28, 2005
    #5
  6. TheOne

    Ben Pfaff Guest

    Flash Gordon <> writes:

    > TheOne wrote:
    >> Would anyone please point me to a list of reentrant C library
    >> functions?

    >
    > Not here, because none of the standard library functions are guaranteed
    > to be re-entrant by the standard.


    Actually, just a few are. Here is the list I provided
    elsethread: abort(), _Exit(), and (with some restrictions)
    signal().
    --
    "For those who want to translate C to Pascal, it may be that a lobotomy
    serves your needs better." --M. Ambuhl

    "Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt
    Ben Pfaff, Nov 28, 2005
    #6
  7. TheOne

    Flash Gordon Guest

    P.J. Plauger wrote:
    > Let's try again.
    >
    > "Ben Pfaff" <> wrote in message
    > news:...
    >
    >> "TheOne" <> writes:


    <snip>

    >>> Does GNU C library make few other functions reentrant on Linux
    >>> platform?

    >> It'd be better to ask about that in a GNU or Linux group.

    >
    > Indeed. I think this list is a little short. Attached below is
    > the list we supply our customers (on request) of writable static
    > data and how we protect it. We use:
    >
    > TLS -- thread-local storage


    <snip>

    I'm sure your library does as you say, but that is no guarantee for any
    other library implementation.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Nov 28, 2005
    #7
  8. TheOne

    Jordan Abel Guest

    On 2005-11-28, Ben Pfaff <> wrote:
    > Flash Gordon <> writes:
    >
    >> TheOne wrote:
    >>> Would anyone please point me to a list of reentrant C library
    >>> functions?

    >>
    >> Not here, because none of the standard library functions are guaranteed
    >> to be re-entrant by the standard.

    >
    > Actually, just a few are. Here is the list I provided
    > elsethread: abort(), _Exit(), and (with some restrictions)
    > signal().


    I wouldn't say it of _Exit() - after all, it could very well destroy the
    other call's context, it just wouldn't matter. It may not apply to
    abort() either.
    Jordan Abel, Nov 29, 2005
    #8
  9. TheOne

    Ben Pfaff Guest

    Jordan Abel <> writes:

    > On 2005-11-28, Ben Pfaff <> wrote:
    >> Flash Gordon <> writes:
    >>
    >>> TheOne wrote:
    >>>> Would anyone please point me to a list of reentrant C library
    >>>> functions?
    >>>
    >>> Not here, because none of the standard library functions are guaranteed
    >>> to be re-entrant by the standard.

    >>
    >> Actually, just a few are. Here is the list I provided
    >> elsethread: abort(), _Exit(), and (with some restrictions)
    >> signal().

    >
    > I wouldn't say it of _Exit() - after all, it could very well destroy the
    > other call's context, it just wouldn't matter. It may not apply to
    > abort() either.


    I don't think you actually read my other article. Here is part
    of what I quoted from the standard there:

    5 If the signal occurs other than as the result of calling the
    abort or raise function, the behavior is undefined if the
    signal handler refers to any object with static storage
    duration other than by assigning a value to an object
    declared as volatile sig_atomic_t, or the signal handler
    calls any function in the standard library other than the
    abort function, the _Exit function, or the signal function
    with the first argument equal to the signal number
    corresponding to the signal that caused the invocation of
    the handler.

    --
    "The lusers I know are so clueless, that if they were dipped in clue
    musk and dropped in the middle of pack of horny clues, on clue prom
    night during clue happy hour, they still couldn't get a clue."
    --Michael Girdwood, in the monastery
    Ben Pfaff, Nov 29, 2005
    #9
  10. TheOne

    P.J. Plauger Guest

    "Flash Gordon" <> wrote in message
    news:-gordon.me.uk...

    > P.J. Plauger wrote:
    >> Let's try again.
    >>
    >> "Ben Pfaff" <> wrote in message
    >> news:...
    >>
    >>> "TheOne" <> writes:

    >
    > <snip>
    >
    >>>> Does GNU C library make few other functions reentrant on Linux
    >>>> platform?
    >>> It'd be better to ask about that in a GNU or Linux group.

    >>
    >> Indeed. I think this list is a little short. Attached below is
    >> the list we supply our customers (on request) of writable static
    >> data and how we protect it. We use:
    >>
    >> TLS -- thread-local storage

    >
    > <snip>
    >
    > I'm sure your library does as you say, but that is no guarantee for any
    > other library implementation.


    Well, it's a pretty good lower bound, at least for all the visible
    functions. Every non-reentrant function we have is one that is
    mandated by the C Standard. That's why I offered the list.

    You're quite right that other libraries can have gratuitous
    lack of reentrancy, or that they can fail to mitigate the
    implicit problem, caused by the C Standard, by adding TLS
    and other mechanisms.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
    P.J. Plauger, Nov 29, 2005
    #10
    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. Hanspeter Moessenboeck

    Compiler generator Coco/R: Reentrant version

    Hanspeter Moessenboeck, Apr 27, 2005, in forum: Java
    Replies:
    0
    Views:
    481
    Hanspeter Moessenboeck
    Apr 27, 2005
  2. junky_fellow

    reentrant functions

    junky_fellow, Oct 30, 2004, in forum: C Programming
    Replies:
    6
    Views:
    444
    Steve Graegert
    Oct 31, 2004
  3. TheOne
    Replies:
    2
    Views:
    1,130
    Maxim Yegorushkin
    Nov 24, 2005
  4. Replies:
    36
    Views:
    1,474
    Anonymous
    Apr 13, 2008
  5. Bill Cunningham

    reentrant functions

    Bill Cunningham, Apr 25, 2012, in forum: C Programming
    Replies:
    13
    Views:
    865
    Michael Angelo Ravera
    Apr 28, 2012
Loading...

Share This Page