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".