lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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.