[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Possible Hex Literal Parsing Bug
- From: Michael Rosenberg <rosenbmi@...>
- Date: Fri, 3 Mar 2017 00:03:31 -0500
In lobject.c the function lua_strx2number will parse a hex numeral as an integer or a floating point. Floating point hex values can be
suffixed with a binary exponent modifier 'p' or 'P' followed by an optionally signed decimal digit sequence. For example, 0x5.3p-1 is
0x53 * 16^(-1) * 2^(-1) = 0x2.98 = 2.59375. Well it appears that lua_strx2number uses an signed integer `exp1` to keep track of the
exponent modifier and does not include overflow detection.
Furthermore, the in-house implementation of lua_strx2number is only used when compiled with the LUA_USE_C89 flag. Otherwise,
lua_strx2number is #defined to be C's strtod implementation. In fact the comment above lua_strx2number says that it follows the C99
specification of strtod (which, it appears, it does, but the semantics of the exponent part are unspecified). However, the two
implementations disagree on this edge case.
When LUA_USE_C89 is defined, we get 0x1.0p-99999999999999999999999999999999 == 2.0
And when it is not defined, we get 0x1.0p-99999999999999999999999999999999 == 0.0
Is this a bug or just undefined behavior?