vfscanf in newlib

[J. Johnston]

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.