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)

Nicholas Wourms wrote:

--- Charles Wilson <> wrote:

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
Why?  Can you please explain your reasoning?  Other then the fact that
conflicts might occur, in which case we should cull out conflicting
function symbols.  But as to additional, non-conflicting functionality,
why be so resistant?

1) because they might not work on cygwin. The need testing *on our platform* BEFORE they are exported from the DLL.

2) deep conflicts: a new function might not itself conflict with something on the cygwin platform, but it might REQUIRE another function or feature in newlib that DOES conflict with a cygwin implementation. Here's one: suppose that somebody added a null "/proc" interface handler to newlib (in the stdio routines?), so that programs which expect /proc could work -- even on a non-glibc linux kernel that was compiled without /proc support (common on embedded platforms).

This would conflict with cygwin's /proc implementation...

3) When I say "willy nilly" that's what I mean. We should NOT automatically export everything the newlib people add. Rather, the default stance should be "we will add the export and '#define in' the declarations at user request or developer need" -- but by default, new additions in newlib are left OUT of the cygwin headers and cygwin1.dll.

The problem here is that functions are added to newlib (and not to cygwin1.dll) -- but the newlib headers ASSUME that the functions are always available. E.g. mismatch.

I've nothing against adding new stuff -- I just think it should be OUR decision, not newlib's -- and it should be done ACTIVELY with TESTING, and not by ACCIDENT.

4) As Chris pointed out, backwards compatibility. Look at the problems you had with the shm exports and db. Every time a new symbol is exported from cygwin1.dll, we raise the possibility that the the new "foo" package will ONLY work with the new cygwin1.dll, and can't work with the old cygiwn1.dll -- even if the OLD 'foo' package worked perfectly well with the old cygwin1.dll, and the new 'foo' package does't REALLY use the new exports from the new cygwin1.dll

e.g. we break backwards compatibility for NO good reason. Unless we really REALLY need the new symbols in cygwin1.dll for some other reason. E.g. we should make an informed decision, aware of the consequences -- not blindly or willy-nilly adding new symbols.

5) Another backwards compatibilty point: once a new symbol is added to cygwin1.dll it can NEVER be removed. If it was a mistake, too bad. If we remove the 'bad' symbol later, then we break EVERY compiled application -- we'd have to bump the cygwin1.dll DLLNUM to '2' : cygwin2.dll -- and we REALLY don't want to do that just because we made a MISTAKE in adding a new symbol.

Adding symbols is a BIG deal -- not to be done cavalierly.

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.

Or maybe it should be the case that we try to stay more in sync with their
additions, deciding at the time they are added if they should be exported.
 If not, then gaurd against the detection.

Yeah -- and in the past, it seemed that newly added newlib symbols WERE guarded against accidental detection in the headers (#ifndef __CYGWIN__) and of course, we have to take active steps to export them (add to cygwin.din)

So, newly added symbols (in newlib) didn't cause breakage -- and once in a while, folks would pop up and say "hey, newlib has this new function and we should export it from the DLL" -- and lo, it would be added to cygwin.din and the header guards removed. Yippee.

That's the way it should be done -- but it requires manpower.

Again, other then the potential for conflicts (which can be delt with),
what is your reasoning?  I put forth the stance that we should flesh out
the cygwin dll, let's use the tools that are at our disposal.  Either
that, or make some sort of separate thing which would allow us access to
these functions.

Covered above.


Unsubscribe info:
Bug reporting:

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