Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Fri, 9 Apr 2004 00:01:56 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: reentrant functions Message-ID: <20040409040156.GA4342@coe> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20040407044353 DOT GA6805 AT panix DOT com> <20040407194643 DOT GM26558 AT cygbert DOT vinschen DOT de> <20040408200223 DOT GD931 AT coc DOT bosbc DOT com> <20040409010034 DOT GA3252 AT coc DOT bosbc DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 09 Apr 2004 04:01:06.0265 (UTC) FILETIME=[48681C90:01C41DE7] On Fri, Apr 09, 2004 at 04:33:26AM +0200, Bas van Gompel wrote: >[You left very little context. I added some.] > >Op Thu, 8 Apr 2004 21:00:34 -0400 >schreef Christopher Faylor >in <20040409010034 DOT GA3252 AT coc DOT bosbc DOT com>: >Christopher Faylor: >>::We also do not want to export _r functions which are unique only to >>::newlib. For instance, I suspect that _mallopt_r is probably not >>::something that we want to export since no other UNIX has it. >:>That's not what was asked... >: >:Aren't you glad I clarified? > >Yeah, sure. But this means I won't be able to help any further >with this, as I don't know which UNIXes export which functions,. Fair enough. My previous message was somewhat garbled. Let me try again. Corinna did not provide enough guidelines in stating what was required. I was attempting to clarify that it wasn't enough to just get a list of all *_r from newlib which are not exported by cygwin. Although I gave a vague "UNIX" guideline I did not offer any clear way for you to determine which functions should be exported. I gave you an example of one such routine but I was too demure in my presentation. mallopt_r is definitely something that we do not want to include, as is realloc_r, and malloc_r, free_r, gettimeofday_r, and tmpfile_r. The reason why these are not desired is that newlib defines a number of _r type functions that do not exist on linux or in the Single UNIX Specification. For a reference of what is acceptable, you can use The Single Unix Specification v3: http://www.opengroup.org/onlinepubs/007904975/toc.htm This reference would be adequate in determining what to include but, if in doubt about something that seems like a useful function, then double checking with linux should be adequate. The SUSv3 reference does not define the mallopt function but functions not ending in _r are not the subject of this exercise. We are trying to export the reentrant routines which have a UNIX analog. We're not trying to bloat cygwin with reentrant routines that no one else uses. There is also another reason not to use mallopt_r -- cygwin doesn't use the malloc version in newlib so exporting any of the _r malloc functions from newlib would cause runtime errors for anyone who used them. >And I asked: Why not export '_mallopt_r' when 'mallopt' is? (I don't >think many UNIXes have 'mallopt', and it is newlib- specific...) Not that it matters but I found mallopt on linux, IRIX, and HP/UX. *hold on a second* Yep. It's on Solaris, too. Again, the criteria is not to export every _r function for which there is an exported non-_r function. We only want to export the ones that make sense for a UNIX environment. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/