This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Problem] mempcpy is missing? (FAQ alert)

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:

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,

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


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]