• Subject: Re: bitwise operators patch breaks Lua operator precedence
• From: Jesús Ruiz de Infante <jesus.ruizdeinfante@...>
• Date: Wed, 02 May 2007 13:46:09 +0200

```Grellier, Thierry wrote:
```
```Oups.
to fix it, around lparser.c:824, change to

static const struct {
lu_byte left;  /* left priority for each binary operator */
lu_byte right; /* right priority */
} priority[] = {  /* ORDER OPR */
{6, 6}, {6, 6}, {7, 7}, {7, 7}, {7, 7},  /* `+' `-' `/' `%' */
#if defined(LUA_BITWISE_OPERATORS)
```
{10, 9}, {6, 6}, {6, 6}, {6, 6}, {7, 7}, {7, 7}, {7, 7}, /* `|' `&' `!' `<<' `>>' `\' */
```   {5, 4},                 /* power and concat (right associative) */
#else
{10, 9}, {5, 4},                 /* power and concat (right associative) */
#endif
{3, 3}, {3, 3},                  /* equality and inequality */
{3, 3}, {3, 3}, {3, 3}, {3, 3},  /* order */
{2, 2}, {1, 1}                   /* logical (and/or) */
};
```
```
Thanks, that solved it.

```
So the operator precedence after the patch is as follows, from higher to lower:
```
^
not # - (unary)
* / %
<< >>
+ -
& ^^ |
..
< > <= >= ~= ==
and
or

Could you please confirm that and perhaps add it to the doc?

```
```
I'll upgrade the patch to 5.1.2 including the fix as soon as I have time.

I've also made a patch which is a bit different. Instead of modifying the number type, it introduces a hex type with a conversion function tohex() from a number. The advantage is that it is implemented with a unsigned long long so 64 bits are useable instead of being bound to 53 bits.
I also wonder if I can change the ^ semantic so that it becomes a xor for hex types instead of introducing ^^. Do you think this approach could suit better to your needs?

```
```
```
I don't think that changing the ^ semantic would have many advantages. It would complicate the patch and I normally can distiguish xor from pow :-)
```
```
Operating on unsiged types would eliminate the ambiguity that exist in the current patch, since till now the right shift oparator >> may or may not do sign extension, depending on the C compiler used.
```
As noted in http://lua-users.org/wiki/BitwiseOperators,
```
the reason is that in Lua all integers are signed, and the underlying C >> operator has an undefined result on signed integers.
```
Compiling Lua with i386 gcc you would get:

0x80000001 >> 4 = 0xf8000000

which may not be what one expected.

--
Mit freundlichen Grüßen

Jesus Ruiz de Infante
(Entwicklung)
HALE electronic GmbH
Eugen-Müller-Straße 18, 5020 Salzburg, Austria
Tel:  +43 (662) 439011 0
Fax:  +43 (662) 439011 9
jesus.ruizdeinfante@hale.at
Firmenbuchnummer: FN 66801m HG Salzburg

--
Scanned by MailScanner.

```