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: <3D23221E.4090105@ece.gatech.edu>
Date: Wed, 03 Jul 2002 12:11:10 -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
X-Accept-Language: en-us
MIME-Version: 1.0
To: Conrad Scott <Conrad DOT Scott AT dsl DOT pipex DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: putc_unlocked in stdio.h but not in libs (1.3.11-3)
References: <3D23052F DOT 3020407 AT perathoner DOT de> <02b501c222a2$c8b9c7a0$6132bc3e AT BABEL>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Conrad Scott wrote:

> "Marcello Perathoner" <marcello AT perathoner DOT de> 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
> suspicious.


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

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