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

["Max Bowsher" <maxb at ukf dot net>]

Charles Wilson wrote:
> Max Bowsher wrote:
> 
>> 3 things:
>> - The issue here was mempcpy, not memcpy
> 
> okay, fine...
> 
>> - Cygwin *doesn't* have a memcpy.h
> 
> It was simply an example.  sure, memPcpy is declared in string.h.  The
> point is, the declaration is found, but the (test) link fails (during
> configury).  and because it fails, your package provides its own
> implementation -- without realizing that the declaration in string.h
> conflicts.  Thus, compile time failure when you actually build the
> project itself.
> 
>> - I still don't understand what you are going to fix - am I missing
>> the obvious? 
> 
> It sounded to me like there was a problem in libintl's headers (and
> possible its configury) where it did not account for the possibility
> of a prior declaration.  This is bad coding.
> 
> When you provide a replacement function, you should always
> define/declare it as
> 
> my_foo()
> 
> not
> 
> foo()
> 
> or use some unique prefix like libintl_foo().  Then, your code should
> call LIBINTL_FOO( (args) ).  Now, if the function is in the system
> libs, 
> then you want
> 
> #define LIBINTL_FOO(a)  foo(a)
> 
> but if it isn't found, then you want
> 
> #define LIBINTL_FOO(a)  libintl_foo(a)

Ah. Now I understand. Thanks for explaining that.

> Now, there are lots of little niggles that can bite you.  I figured I
> would have to work at this a bit -- and I'd save this thread and get
> around to it when I next update gettext.  BUT, I really didn't read
> the 
> initial message that closely; "libintl has a problem"  "Okay, that's
> my job to fix it."
> 
> Am I wrong? Without Chris's change to cygwin.din, is the problem
> actually somewhere *else* and not in libintl.h/etc?

No, you are right.


Max.


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