Re: 1e50 == 1?

[Matthew Paul Del Buono <delbu9c1@...>]

>   I'm pretty certain casting a negative number to an
>   unsigned number is
>   a bad thing. Although I could be wrong. In any case,
>   on a system that
>   uses a sign bit, instead of two's compliment, the
>   equation wouldn't work.

My apologies, I'm used to coding for embedded systems where I know exactly what's going on in the architecture; I had assumed that C guaranteed two's compliment representation, but the research I have done since then suggests otherwise.

>
>   The best way to check if the number is a valid
>   integer is to simply do
>
>   lua_Number n = luaL_checknumber(L, 2);
>   int k = (int) n;
>   if (lua_Number)k != n {
>     // raise error
>   }

While I like that this will, as you have said, take care of issues like string.rep("foo", math.pi), I dislike the fact that you're testing a double with an equality operator.

Now I know most people agree floating point imprecision is an overused excuse to not use equality tests on doubles (I agree), but fact is that we don't know where this number came from. Sure, we could be looking at a simple case like the examples already proposed, but we could also be looking at a case where n has gone through 1000 math operations. I don't think it's acceptable that Lua opens itself to a possible bug due to roundoff errors, even in the event that it is extremely, extremely unlikely (which it is). 

I have been told that the the #define INT_MAX is standard.... is it? If so, that would be a simple replacement for the slightly hacky math I did to come up with the maximum representable value of an integer.

Alternatively, pow(2, sizeof(int)*8-1) is always an option... but I preferred not to do that because, imho, placing the pow() function call there is an unnecessary performance hit.

So what about INT_MAX?

-- Matthew P. Del Buono a.k.a. Shirik