Re: bitwise operators patch breaks Lua operator precedence

[Jesús Ruiz de Infante <jesus.ruizdeinfante@...>]

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.