Re: CVS psmith make: Whoops; configure wasn't looking for memmove.

[Paul D. Smith]

%% Soren A <address@hidden> 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 <address@hidden>          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