This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: vfscanf in newlib
- To: cygwin-developers at cygwin dot com
- Subject: Re: vfscanf in newlib
- From: "J. Johnston" <jjohnstn at cygnus dot com>
- Date: Mon, 23 Apr 2001 22:05:09 -0400
- CC: cygwin-developers-digest-help at cygwin dot com, newlib at sources dot redhat dot com
- Organization: Red Hat Inc.
- References: <987861904.20126.ezmlm@sources.redhat.com> <3AE1C5B2.B63F2B54@ece.gatech.edu> <20010421192518.E4033@redhat.com>
Christopher Faylor wrote:
>
> On Sat, Apr 21, 2001 at 01:38:58PM -0400, Charles S. Wilson wrote:
> >Didn't somebody already do a threadsafeness audit of newlib? If so,
> >then we don't want to break threadsafeness with these changes. I'm not
> >familiar with threaded code in C; what is neccessary to insure that a
> >given function is both reentrant and threadsafe (if a block of code is
> >threadsafe it is automatically reentrant, but a reentrant block is not
> >necessarily threadsafe, right?)
>
> That's right.
>
> AFAIK, newlib is not guaranteed to be thread safe.
>
This is correct. File access, for example, is unprotected; an application must police itself.
Newlib's memory allocation routines (libc/stdlib/mallocr.c) use static linked lists of memory chunks
and are unprotected by default. While the code has lock/unlock calls to protect accesses to the
shared lists, newlib only supplies default empty stubs (libc/stdlib/mlock.c). The
environment-variable routines (getenv/setenv/putenv) use a similar lock mechanism with default empty
stubs provided (libc/stdlib/envlock.c). An application wishing to protect these particular routines
could provide proper versions of the mutex routines for the specific platform.
-- Jeff J.