On Nov 28 2021, Paul Smith wrote:
>> The C standard defines the largest unsigned long long value
>> as 18446744073709551615, the largest signed long long value
>> as 9223372036854775807, and the smallest signed long long value as -
>> 9223372036854775808. So, the definition cannot be wrong in any
On Nov 28 2021, Paul Smith wrote:
> The C standard defines the largest unsigned long long value
> as 18446744073709551615, the largest signed long long value
> as 9223372036854775807, and the smallest signed long long value as -
> 9223372036854775808. So, the definition cannot be wrong in any
>
On Sun, 2021-11-28 at 15:49 +0100, Jouke Witteveen wrote:
> I fully agree, but was not aware of the robustness of INTSTR_LENGTH.
> It felt a bit fragile when I spotted its definition in makeint.h.
The C standard defines the largest unsigned long long value
as 18446744073709551615, the largest
On Sun, Nov 28, 2021 at 3:20 PM Paul Smith wrote:
>
> 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
On Sun, Nov 28, 2021 at 3:33 PM Paul Smith wrote:
>
> On Sun, 2021-11-28 at 08:24 +0100, Jouke Witteveen wrote:
> > On the user side, strcmp could now probably be defined something like
> > $(and $(intcmp $(words $1),$(words $2)),$(findstring x $1 x,x $2 x))
>
> I don't think this is equivalent
On Sun, 2021-11-28 at 08:24 +0100, Jouke Witteveen wrote:
> On the user side, strcmp could now probably be defined something like
> $(and $(intcmp $(words $1),$(words $2)),$(findstring x$1x,x$2x))
I don't think this is equivalent since a putative strcmp would also do
greater / less than
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
On Sun, Nov 28, 2021 at 2:45 PM Paul Smith wrote:
>
> On Sun, 2021-11-28 at 08:24 +0100, Jouke Witteveen wrote:
> > Thanks for sending this message, I would have otherwise prepared and
> > sent an updated patch series today. My plan was to expand to RHS in
> > the two-argument case if both values
On Sun, 2021-11-28 at 08:24 +0100, Jouke Witteveen wrote:
> Thanks for sending this message, I would have otherwise prepared and
> sent an updated patch series today. My plan was to expand to RHS in
> the two-argument case if both values are equal. I assume you also
> updated the documentation
On Sun, Nov 28, 2021 at 5:02 AM Paul Smith wrote:
>
> On Mon, 2021-11-15 at 20:49 +0100, Jouke Witteveen wrote:
> > It may be obscure, but how about we implement this as well? Sure, the
> > two-argument form of $(compare) will be a little inconsistent, but it
> > may be useful.
>
> I applied this
On Mon, 2021-11-15 at 20:49 +0100, Jouke Witteveen wrote:
> It may be obscure, but how about we implement this as well? Sure, the
> two-argument form of $(compare) will be a little inconsistent, but it
> may be useful.
I applied this three-patch set.
I left the argument order as you originally
On Tue, Nov 16, 2021 at 10:28 AM Edward Welbourne
wrote:
>
> On Sun, Nov 14, 2021 at 8:42 PM Paul Smith wrote:
> > It's even possible to allow $(compare ,) with no other
> > arguments and say that if they are equal then it expands to the value,
> > else it expands to the empty string, to give a
On Sun, Nov 14, 2021 at 8:42 PM Paul Smith wrote:
> It's even possible to allow $(compare ,) with no other
> arguments and say that if they are equal then it expands to the value,
> else it expands to the empty string, to give a very short-circuited
> equality statement.
I should point out one
On Sun, Nov 14, 2021 at 8:42 PM Paul Smith wrote:
>
> On Wed, 2021-11-10 at 18:19 +0100, Jouke Witteveen wrote:
> > On Mon, Nov 8, 2021 at 4:08 PM Paul Smith wrote:
> >
> > > On Fri, 2021-07-16 at 14:04 +0200, Jouke Witteveen wrote:
> > > > $(compare
> > > >
On Wed, 2021-11-10 at 18:19 +0100, Jouke Witteveen wrote:
> On Mon, Nov 8, 2021 at 4:08 PM Paul Smith wrote:
>
> > On Fri, 2021-07-16 at 14:04 +0200, Jouke Witteveen wrote:
> > > $(compare
> > > @var{lhs},@var{rhs},@var{lt-part}[,@var{eq-part}[,@var{gt-part}]])
> > Let me ask this: would it be
On November 10, 2021 12:19 PM, Jouke Witteveen wrote:
> To: psm...@gnu.org
> Cc: bug-make
> Subject: Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison
>
> On Mon, Nov 8, 2021 at 4:08 PM Paul Smith wrote:
> >
> > On Fri, 2021-07-16 at 14:04 +
On Fri, 2021-07-16 at 14:04 +0200, Jouke Witteveen wrote:
> +@item $(compare
> @var{lhs},@var{rhs},@var{lt-part}[,@var{eq-part}[,@var{gt-part}]])
Let me ask this: would it be better to use a format of:
$(compare , , [, [, ]])
Then the rule is, if the values are equal we get the part, if lhs
Also perhaps the more general mathematical function
On Mon, Sep 13, 2021 at 10:04 PM Randall S. Becker
wrote:
> On September 13, 2021 2:40 PM, Jouke Witteveen wrote:
> >On Fri, Jul 16, 2021 at 2:04 PM Jouke Witteveen
> wrote:
> >>
> >> Numbers can come from $(words ...), automatic variables
On September 13, 2021 2:40 PM, Jouke Witteveen wrote:
>On Fri, Jul 16, 2021 at 2:04 PM Jouke Witteveen wrote:
>>
>> Numbers can come from $(words ...), automatic variables such as
>> $(MAKELEVEL), from environment variables, or from shell output such as
>> through $(shell expr ...). The
On Fri, Jul 16, 2021 at 2:04 PM Jouke Witteveen wrote:
>
> Numbers can come from $(words ...), automatic variables such as
> $(MAKELEVEL), from environment variables, or from shell output such as
> through $(shell expr ...). The $(compare ...) function allows
> conditional evaluation controlled
20 matches
Mail list logo
