Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <20020703163918.39013.qmail@web21007.mail.yahoo.com>
Date: Wed, 3 Jul 2002 09:39:18 -0700 (PDT)
From: Nicholas Wourms <nwourms AT yahoo DOT com>
Subject: Re: putc_unlocked in stdio.h but not in libs (1.3.11-3)
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>,
   Conrad Scott <Conrad DOT Scott AT dsl DOT pipex DOT com>
Cc: cygwin AT cygwin DOT com
In-Reply-To: <3D23221E.4090105@ece.gatech.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- 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?

>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.

> 
> Perhaps in this case.  But in general, adding more and more exports to 
> cygwin.din is not the answer.

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.
 
> 
> > 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...

I tend to agree with Conrad on this point.  Let's not be blinded by
paranoia...  Change is good!

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

--
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/