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: Sat, 15 Feb 2003 18:39:41 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: [Problem] mempcpy is missing? (FAQ alert) Message-ID: <20030215233941.GA12171@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i On Sat, Feb 15, 2003 at 03:10:38PM -0700, Roger Sayle wrote: >However you might also consider that there still remain a significant >number of potentially problematic function prototypes from cygwin's >header files: strndup, exp2, scalbln, tgamma, nearbyint, lrint, round, >lround, trunc, remquo, fdim, fmax, fmin, etc... Unfortunately, mempcpy >was just the tip of the iceberg. Um, yeah. We obviously *know about this already*. For the record, here was my checkin: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.din.diff?cvsroot=src&r1=1.76&r2=1.77 As you can see, I finally bit the bullet and checked in most of the functions from libc in newlib that were not exported in cygwin. This will, of course, be a moving target, and we will not want to export every single function as soon as it shows up. I had concerns about unnecessarily bloating the Cygwin DLL, which was why we hadn't done this previously. I've thrown in the towel now, though. Rest assured that we are well aware of the fact that we could use ifdefs in include files. And, my "FAQ alert" addition to the subject was meant to signal the FAQ maintainer that they should add a generic entry about this problem, not a specific "mempcpy doesn't work and here's why" section. I am quite sure that the FAQ maintainer would have correctly assumed that I meant to add a generic section on this issue. The entry in the FAQ which talks about what's exported says this: "To see if a function is implemented but not listed here, check for the presence of the call in the file winsup/cygwin.din in the sources. In addition, you may want to read the source code corresponding to the call to verify that it is not a stub." I think that + the addition of some words to say that not everything is exported from newlib but there may be declarations in header files should make the situation clear. I still think that, given what a configure script is supposed to accomplish, this kind of thing should be checked for. I don't see how anyone could argue with that fact, but it's really not worth any more discussion. cgf -- 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/