This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: putc_unlocked in stdio.h but not in libs (1.3.11-3)

Conrad Scott wrote:

"Marcello Perathoner" <> 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:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]