%% Soren A <[EMAIL PROTECTED]> writes: >> I don't understand this. If bcopy() isn't there and memmove() is >> (which wasn't being checked but now will be) then the code in make.h >> as-is works. >> >> Doesn't it?
sa> It really doesn't. [...] Please note my parenthetical statement (also the message in the thread which you replied to): in the code you started with, there was a missing configure script check for memmove(). Because of that, no matter whether or not there was a memmove() on the system, the HAVE_MEMMOVE constant would _never_ be defined. This is obviously a bug and this is what I fixed in the CVS commit which started this thread. After this fix MINGW systems, which do have memmove(), will define the HAVE_MEMMOVE macro. And as you've stated, bcopy() is not defined on MINGW. In that case, the original test: # if defined(HAVE_MEMMOVE) && !defined(bcopy) will be true and bcopy() will be translated into memmove(). Which is what you want. In other words: yes, I agree that there was a bug in the code you started with (3.80rc1), but the bug is not that make.h is wrong, but rather that the configure script was never setting HAVE_MEMMOVE even on systems which did have it. sa> On Cygwin, bcopy() doesn't present a problem. In fact this is sa> because the Cygwin system headers define bcopy() as a macro (in sa> fact using memmove(), that is, the macro resolves to a call to sa> memmove()). sa> On MinGW, I got link time errors due to all the bcopy() instances sa> being undefined references. When I gained the understanding of sa> which gcc (cpp) flags to use when compiling to catch undefined sa> functions, it showed that there is no bcopy() whatsoever in sa> MinGW. It is not defined as a macro nor existant as a real sa> function. That's fine. Then when HAVE_MEMMOVE is set, it will translate bcopy() into memmove(), just as it should. You're misunderstanding the point of the check for a bcopy() macro. The check for a bcopy() macro is meant to _avoid redefining_ bcopy() as a macro, if it already exists as a macro. That is, some systems define memmove(), then they define (in the system headers!) bcopy() as a macro which invokes memmove() (just like make.h does). If make.h includes a header file that #defines bcopy(), then make.h _ALSO_ #defines bcopy(), you (very likely) get a compile error. So the check is: a) If we have memmove(), b) AND there is not already a bcopy() macro defined, c) THEN define a bcopy() macro to be memmove() To reiterate, the problem was (a) was never true, so the THEN clause was never taken. sa> Yes, as i wrote above, this is a point you are quite correct on. I sa> did a lousy job of re-writing the macro. However, now that you've sa> looked for yourself I think you can see that it DOES need to be sa> re-written. The old way: [as you wrote] >> The current behavior says "if we have memmove() and bcopy() is not >> a macro (because some systems define it as a macro and in that case >> if we redefine it we will get an error) then define bcopy() as a >> macro that invokes memmove()". sa> Somehow that just isn't working. Exactly right: it _wasn't_ working because of the autoconf bug--which the fix I made in CVS will resolve. >> Your change says "if configure can't find a bcopy(), then define it to >> be memmove()". >> >> I think the only practical difference (except for weird cases where >> configure can't find bcopy() but it does end up being defined as a >> macro in the actual build, where your change would fail--but I >> doubt that would happen in real life) is that the original prefers >> memmove() if it exists, and your change prefers bcopy() if it >> exists. sa> You've completely lost me. Either you are wrong now or I am sa> completely not understanding how to read a C macro statement. Or sa> your wording is sufficiently different from your intention that I sa> am being confused by it. No, I think I wrote what I meant. This is what I meant: Consider a platform on which there is no bcopy() and only memmove(). Then (now that configure.in is fixed) we will define a macro that translates bcopy() into memmove(). Now consider a platform on which there is a bcopy() and no memmove(). Then we will not define any macros, and we will invoke bcopy() directly. Up until now, our two solutions are identical (with the caveat below regarding the "weird case"). However, here is where they are different: Suppose a platform has _BOTH_ bcopy() and memmove() functions. Then, my solution will prefer the memmove() solution (that is, it will define bcopy() as a macro expanding to memmove()). Your solution will prefer the bcopy() solution (since HAVE_BCOPY will be true) and use the bcopy() function without any macro. That's all I meant. sa> The new macro statement says, to me: "if *configure* finds that sa> bcopy() is not present, then define bcopy() as a macro that sa> resolves to a call to memmove() [with the function parameters sa> suitably rearranged]." My change doesn't prefer bcopy(), it sa> defines bcopy() as a macro that resolves to memmove(). Yes, but as I show above your change prefers bcopy() in the case where both exist (if only one exists it doesn't make sense to talk about "preferring" one: if there is only one choice then the other choice is an error). sa> As for the former, your "weird case" is what I cannot sa> understand. This section of make.h is the only place where we get sa> to determine what the compiler will think bcopy() means for the sa> build; I don't understand why you'd phrase it as if the build were sa> something external to the parsing of this header. As I mention above, there are other header files included, namely the system header files like memory.h or stdlib.h or whatever. It's the case where _THESE_ system header files define bcopy() as a macro that the test is guarding against. sa> I'll write a new macro block for this issue and make a new diff in sa> the next couple of days I believe that if you pull the CVS sources (or wait a day or so for the next rc build) you will find that you will not have this problem any longer. If you still do there is something deeply strange going on. sa> However, the only core C library function that appeared as a sa> problem to me was bcopy() so when this gets taken care of a whole sa> category of portability issues will (likely) be done with and sa> other things can be focused on. There are MANY more sa> build-configuration issues to be resolved, Earnie Boyd has written sa> about some of that separately. I've no doubt whatsoever that there are whole classes of problems waiting to be discovered. The autoconfiscation of GNU make has never even _considered_ the needs of a Windows platform. As was pointed out a few times, it's pretty obvious when you consider that there isn't any configure support anywhere for the code in the w32 subdirectory. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
