> This really annoys me and keeps me on the fence about gnulib, and
> prevents me from completely switching (for example, moving to modern
> glob/fnmatch). I've only pulled in some relatively simple elements so
> far.
>
> So... I'm not sure which way to fall on that.
Apparently gnulib requires
>
> I believe the form being considered is:
>
> $(math OPERATOR,LIST)
I am still partial to `$(math ...)`
with only one argument.
> The only one I'm not sure about is overflow. That will need some
> thought. Gnulib contains a comprehensive set of macros to deal with
> overflow, in various ways.
On Mon, 2020-05-25 at 13:28 -0500, Pete Dietl wrote:
> Question about 64-bit, what happens when compiling make for a 32-bit
> system? I don’t think c90 has `stdint.h`... maybe there’s something
> in gnulib. Anyway, would we want to support 64 bit integers even on
> 32-bit platforms?
32bit platform
On Mon, 2020-05-25 at 12:07 -0400, Sam Kendall wrote:
> I'd like to raise some questions that I think any proposal ought to
> answer. I'll assume a straw man proposal: there's one function, and
> it takes one of the following forms:
>
> $(math OPERATOR,VALUE1,VALUE2)
> $(math OPERATOR,VALUE1)
I b
`long long` was not introduced until c99, neither was `stdint.h`, but
perhaps gnulib can help us out here.
On Mon, May 25, 2020 at 3:44 PM Pete Dietl wrote:
>
> > I was not even considering specifying the base of the the resulting
> > expansion. I was assuming it would always be base 10. I don'
> I was not even considering specifying the base of the the resulting
> expansion. I was assuming it would always be base 10. I don't have
> any good way to specify the output form.
>
> I was only considering the parsing of input (constant) values: whether
> we wanted to support 0xfff, 0o777, 0b1
On Mon, 2020-05-25 at 10:10 +, Edward Welbourne wrote:
> > > Mult-base support: should we support only base 10 integer
> > > constants in
> > > expressions, or also hex/octal constants?
> > I vote for decimal, hex, and binary.
> > Octal if you really want it.
>
> A case for octal and bitwise a
On Mon, 25 May 2020 at 18:34, Pete Dietl wrote:
> Question about 64-bit, what happens when compiling make for a 32-bit
> system? I don’t think c90 has `stdint.h`... maybe there’s something in
> gnulib. Anyway, would we want to support 64 bit integers even on 32-bit
> platforms?
>
> If at all poss
Question about 64-bit, what happens when compiling make for a 32-bit
system? I don’t think c90 has `stdint.h`... maybe there’s something in
gnulib. Anyway, would we want to support 64 bit integers even on 32-bit
platforms?
Sam Kendall (25 May 2020 18:07) observed:
> If you have relational or equality operators, what does the boolean
> result look like? If the result is 1 for true and 0 for false, then
> you get a bad surprise: $(if $(math =,5,6),yes) expands to yes. If the
> answer is some nonempty string for true an
I'd like to raise some questions that I think any proposal ought to answer.
I'll assume a straw man proposal: there's one function, and it takes one of
the following forms:
$(math OPERATOR,VALUE1,VALUE2)
$(math OPERATOR,VALUE1)
A binary operator (first form) is one of + - * and /. The only unary
Pete Dietl (22 May 2020 09:18)
> As for a name for $(cond), we could call it
> $(alu ...)
> And put arithmetic and logical operations in it :)
Amusing as this is, I don't think it's a good name !
> I don’t like using $(cond)
> Because because I sort of want to option to implement cond like in Sch
>>> Bit Manipulation:
>>> --
>>> * and
>>> * or
>>> * xor
>>> * complement
>>> * left shift
>>> * right shift
>>
>> Maybe. I have a hard time coming up with uses for these, other than
>> possibly the shift operators (but multiplication/division can be used
>> instead).
Pete Di
13 matches
Mail list logo
