delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/02/15/18:38:27

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
Date: Sat, 15 Feb 2003 18:39:41 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
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: <Pine DOT LNX DOT 4 DOT 44 DOT 0302151434380 DOT 15904-100000 AT www DOT eyesopen DOT com>
Mime-Version: 1.0
In-Reply-To: <Pine.LNX.4.44.0302151434380.15904-100000@www.eyesopen.com>
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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019