Re: Weird embedded literal number/compiler issue

[Tim Maxwell <timmaxw@...>]

Amazing, that was my whole prob.  It started working once I put in source-code

Has anybody ever recompiled luac to support switching endian states?

On Sun, Aug 10, 2008 at 12:47 PM, Mike Crowe <drmikecrowe@gmail.com> wrote:

Yes!  I didn't even think of that.

I guess I need to try the files in source-code form.

On Sun, Aug 10, 2008 at 12:43 PM, Mike Crowe <mike@mikeandkellycrowe.com> wrote:

Yes!  I didn't even think of that.

I guess I need to try the files in source-code form.

On Sun, Aug 10, 2008 at 12:09 PM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:

> The problem seems to be with using literal numbers.  If I do:
>
> i = 1
>
> and then log what I is, I get:
>
> = 5.2998088236266e-315

How do you log what you get?

It seems to me to be an endianness problem. On big endian machines, you get
1 =                     3FF0000000000000
5.2998088236266e-315 =  000000003FF00000
(both 8-byte doubles)

Are you using luac on the PC and then transfering the result to the ARM?

The Lua compiler writes headers to the top of every file using this function:

void luaU_header (char* h)

{

 int x=1;

 memcpy(h,LUA_SIGNATURE,sizeof(LUA_SIGNATURE)-1);

 h+=sizeof(LUA_SIGNATURE)-1;

 *h++=(char)LUAC_VERSION;

 *h++=(char)LUAC_FORMAT;

 *h++=(char)*(char*)&x; /* endianness */

 *h++=(char)sizeof(int);

 *h++=(char)sizeof(size_t);

 *h++=(char)sizeof(Instruction);

 *h++=(char)sizeof(lua_Number);

 *h++=(char)(((lua_Number)0.5)==0); /* is lua_Number integral? */

}

You can see that it doesn't check for the endianness of lua_Number.  Perhaps the next Lua release that breaks binary compatibility in compiled files should also include some sort of check for the endianness of lua_Number.

Maybe there needs to be a tool to convert compiled Lua files between different platforms.

Tim Maxwell