Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3D233C5F.1080502@ece.gatech.edu>
Date: Wed, 03 Jul 2002 14:03:11 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: Nicholas Wourms <nwourms AT yahoo DOT com>
CC: Conrad Scott <Conrad DOT Scott AT dsl DOT pipex DOT com>, cygwin AT cygwin DOT com
Subject: Re: putc_unlocked in stdio.h but not in libs (1.3.11-3)
References: <20020703163918 DOT 39013 DOT qmail AT web21007 DOT mail DOT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Nicholas Wourms wrote:

> --- Charles Wilson <cwilson AT ece DOT gatech DOT edu> wrote:
> [SNIP]
> 
>>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.  
>>
> 
> 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.


--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/