lua-users home
lua-l archive

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


Shmuel Zeigerman wrote:
> Though formally it's not Lua's fault, in practice it leads to problems.
> Are the benefits of using those 2 assembly instructions (yet another
> piece of non ANSI C) big enough to justify fighting with compatibility
> issues?

That's besides the point. You get a crash there because it's
called early on. If you add a work around for this one, you may
get crashes in plenty of other places. Even if you're 100% sure
your application never divides by zero or calls math.sqrt(-1) ...
are you absolutely confident not to produce infinities and never
to cause *any* other trapping FPU operations?

IMHO you have two options: a) let it crash and tell everyone the
Delphi runtime is the culprit or b) check for the bad FPU setting
on startup and print a big error message.

> Is there a benchmark showing noticeable gain in performance of this  
> piece versus the other ("non-Microsoft") variant of lua_number2integer,  
> or maybe this was introduced to avoid issues with DirectX?

The two variants are almost the same speed. It was added to avoid
DirectX trouble (dig in the mailing list).

[
But IMHO we have the same issue here: it's just hiding another
class of problems. E.g. table indexes can silently go to the wrong
places if the FPU precision is reduced due to the missing DirectX
initialization flag.

I generally prefer designs that "fail hard and fast".
]

--Mike