lua-users home
lua-l archive

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

I presume the number2int that fails is the arithmetic version not
the inline assembler. Or do both fail?


On 10/21/05, Mike Pall <> wrote:
> Hi,
> Roberto Ierusalimschy wrote:
> > > This will probably be due to something mucking about with global fpu
> > > flags, probably dx I remember having issues with this sort of thing
> > > before.
> >
> > Can you give more details about that problem?
> This is a well known issue when mixing DirectX and other
> floating-point code. This affects lots of programs and not
> just Lua. It has been mentioned on the list several times.
> Quoting:
>  "Direct3D will set the floating-point unit to single-precision,
>   round-to-nearest as part of initialization (unless the
>   D3DCREATE_FPU_PRESERVE flag is used, in which case the FP control
>   word is untouched)."
> Summary: This is not a Lua problem. It's DirectX violating the
> x86/x87 ABI which requires the FP control-word to be in a specific
> state. Lua depends on the standard setting in several places.
> The new thing in Lua 5.1 is that it's _guaranteed_ to break,
> because the new number2int conversion trick fails. And this one
> is used in lots of places (e.g.: x = t[1]).
> With earlier Lua versions it failed only intermittently -- which
> is worse, because you may never find out.
> Maybe this fact deserves a special mention in the manual.
> Bye,
>      Mike