Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

[Paul Smith]

On Sun, 2021-11-28 at 14:57 +0100, Jouke Witteveen wrote:
> > Since the two arguments are equal, it doesn't matter which of LHS
> > or RHS we return.
> 
> They could differ for instance when one of them contains a '+'-sign.
> My reason for using LHS is that we already have a string for it.

I don't think that it's necessary return the exact string.  If the user
wanted a string match they can do that other ways.  Returning the
"absolute value" (stripping leading +/-, leading 0's, etc.) seems more
useful to me.

>  By using sprintf, we need to make the buffer big enough, which in
> turn requires INTSTR_LENGTH to be fitting for whatever width a long
> has on the current platform.

That's already the case; GNU make defines this constant to be large
enough to hold the largest possible (8-byte) integer value, regardless
of platform.  This is used in various places when showing output etc.

> > However, now that I think about it I need to change the code more: we
> > need to be using "long long" here not just "long".  While on Linux etc.
> > a "long" is 8 bytes, on Windows "long" is only 4 bytes.
> 
> I was hoping this would not be necessary, and I cannot think of a
> typical use case where make is a good fit for dealing with large
> integers. The benefit of "long" is that strtol is more widely
> available than strtoll.

I see what you mean, but I _really_ don't like the idea of GNU make
working differently on different platforms, even if such use cases are
rare.  I can imagine a situation where, for example, someone wants to
compare the sizes of files and if one of the files is >4G then it will
work on Linux and fail on Windows.