This is the mail archive of the
mailing list for the Cygwin project.
Re: putc_unlocked in stdio.h but not in libs (1.3.11-3)
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Conrad Scott <Conrad dot Scott at dsl dot pipex dot com>
- Cc: cygwin at cygwin dot com
- Date: Wed, 03 Jul 2002 12:11:10 -0400
- Subject: Re: putc_unlocked in stdio.h but not in libs (1.3.11-3)
- References: <3D23052F.firstname.lastname@example.org> <02b501c222a2$c8b9c7a0$6132bc3e@BABEL>
Conrad Scott wrote:
"Marcello Perathoner" <email@example.com> wrote:
According to the FAQ putc_unlocked is not implemented
and you don't find it in the libraries.
But it is present in the stdio.h header.
The level of synchronicity on this issue is starting to get me
It does appear that the newlib folks have been adding LOTS of new
functions recently, without appropriate guards in the header files.
They are assuming that "if it goes into libc.a or libm.a, then it WILL
be available to programs that link in -lc or -lm".
Not an unreasonable assumption in general, but I *think* they used to be
more careful about cygwinisms: where the above assumption is NOT true.
(The functions are only available to clients IFF they are exported by
the cygwin1.dll -- otherwise, the very existence of the functions should
be hidden via #ifndef __CYGWIN__ in the header files)
I *think* they used to be more careful about those cygwinisms.
However, the correct answer is NOT, IMO, to willy-nilly export
everything in libc/libm from cygwin1.dll -- even if dll size were not an
issue. Unfortunately, I don't know what the "correct" answer is, short
of a "cleanup squad" that provides the newlib people with the
appropriate #ifndef __CYGWIN__ patches -- since the newlib folks are no
longer being very careful about that issue on their own.
Taking up Corinna's point from yesterday, none of the unexported
functions from <stdio.h> are SUSv3 functions, they're all BSD-isms.
Then again, they are all just wrappers that call other (already
exported) functions, so size isn't much of an issue and you don't get
any extra funcionality.
Perhaps in this case. But in general, adding more and more exports to
cygwin.din is not the answer.
A more important point I've tripped over is that cygwin doesn't seem
to provide implementations of the flockfile etc. functions used by
stdio to lock the FILE objects, and so the current version is not
thread-safe. Is that true? says I in some pain, having just gone
through cygserver replacing all <iostream.h> calls with <stdio.h>
calls to avoid a thread-safety problem in the C++ library :-(
Dunno about this...
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html