List of reentrant C library functions

T

TheOne

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

Ben Pfaff

TheOne said:
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.
 
P

P.J. Plauger

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


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

Indeed.
 
F

Flash Gordon

TheOne said:
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.
 
P

P.J. Plauger

Let's try again.

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


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

Ben Pfaff

Flash Gordon said:
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().
 
F

Flash Gordon

P.J. Plauger said:
Let's try again.




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

Jordan Abel

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

Ben Pfaff

Jordan Abel said:
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.
 
P

P.J. Plauger

<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
 

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

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top