3

I am currently using Windows on my default development system and Linux on my server where I deploy my Lua scripts. For Windows there are only several 32 bit interpreters like Lua for Windows one I currently use (at least as far as i know). On the server the interpreter is running the scripts on 64 bits.

Now my question is: Is it possible to check on which architecture the script is running (probably similar to the _ENV variable for the version)?

If there is any 64 bit Windows Lua interpreter feel free to leave a comment on this matter. Thank you in advance.

creyD
  • 1,972
  • 3
  • 26
  • 55

5 Answers5

4

This is how to determine your OS bitness, not your compiler bitness (you can run 32-bit Lua.exe on Windows 64-bit).

local arch
if (os.getenv"os" or ""):match"^Windows" then
   print"Your system is Windows"
   arch = os.getenv"PROCESSOR_ARCHITECTURE"
else
   print"Your system is Linux"
   arch = io.popen"uname -m":read"*a"
end
if (arch or ""):match"64" then
   print"Your system is 64-bit"
else
   print"Your system is 32-bit"
end
Egor Skriptunoff
  • 23,359
  • 2
  • 34
  • 64
  • 1
    I know that I can run a 32 bit Lua on my 64 bit system, that is what I am currently using. Thank you, but this sadly doesn´t answer my question. – creyD Jan 04 '18 at 14:48
  • The answer informs you of a way to check if it is 32 or 64 bit. You can access the environment variables of the system with os.getenv() - that is if you have libraries loaded. After that you can check if a number is available to be 64bit by flooring a number of 64_BIT_INTEGER_MAX_SIZE in lua5.3.x. Which is 255^8. In any case the number is truncated during the floor to 32_BIT_INTEGER_MAX_SIZE, you are on a 32bit system. – user2262111 Jan 05 '18 at 14:21
2

If you can get the executable that runs the script, you can probably look at its header on Windows and Linux to check if it's 32bit or 64bit application; here are suggestions on how to do it on Windows.

I'm also interested in simpler ways to do it from a Lua script (and the one that works with Lua and LuaJIT interpreters), as I ran into a case when I'd like to reference different paths depending on whether 32bit or 64bit library needs to be loaded without the user having to specify those paths.

Paul Kulchenko
  • 25,884
  • 3
  • 38
  • 56
1

The simplest way is to test number limit. In 32 bit Lua 0xffffffff(8'f's) would be the max int number and 0xfffffffff(9'f's) would overflow try flowing code

function _86or64()
    if(0xfffffffff==0xffffffff) then return 32 else return 64 end
end

print(_86or64());
Yi Zhu
  • 19
  • 1
0

Why would you need that knowledge?

Normally there's nothing you can do on Lua side that would depend on underlying host architecture. To perform something specific to the host, you would need to write some native code, but then you will know the architecture you will be compiling for.

There's one possible way though (maybe there's more). You can compile dummy function with string.dump() and analyze bytecode header. The header is different between Lua versions, so you should check the version first to know location of "system parameters" field. If Lua interpreter wasn't altered, then the field that stores size_t size in bytes would be different for 32- and 64-bit host.

Vlad
  • 5,450
  • 1
  • 12
  • 19
  • 1
    On Lua 5.3 `size_t` width could be determined as `#string.pack("T",0)*8` – Egor Skriptunoff Jan 04 '18 at 12:55
  • In fact there is: I am running a large calculation which needs more than 2 GB of RAM (not optimal, I know). If this runs on a 64 bit machine everything runs as expected but because of the smaller memory allocation of 32 bit Lua interpreters the script endlessly executes. – creyD Jan 04 '18 at 13:54
-2

Here's a function that tells you whether you are on a 32 or 64-bit LUA:

function bits() return 1<<32==0 and 32 or 1<<64==0 and 64 end
Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
Jonathan Cohler
  • 1
  • 1
    Please edit your answer to format code into code blocks. – DapperDuck Jan 03 '21 at 17:26
  • @DapperDuck thanks for the heads up. It seems like Jeremy Caney already took care of it. – Jonathan Cohler Jan 05 '21 at 21:38
  • This is not necessarily true (depending on *LUA\_32BITS*). -1. – CristiFati Apr 15 '22 at 07:04
  • @CristiFati What is not necessarily true? That code works perfectly and does exactly what it says. It "tells you whether your are on a 32 or 64-bit LUA". The compile time parameter LUA32BITS sets LUA to run with 32 bit integers and floats. And the code above is RUNTIME and tells you what LUA is doing at RUNTIME. – Jonathan Cohler Apr 16 '22 at 16:38
  • 1
    It's not true for 32bit: https://www.lua.org/manual/5.4/manual.html#2.1. – CristiFati Apr 16 '22 at 16:57
  • More details: `"c:\Program Files (x86)\Lua\Lua\5.4.4\bin\lua.exe" -e "print(1 << 32 == 0, 1 << 64 == 0, os.getenv(\"PROCESSOR_ARCHITECTURE\"))"` outputs: `false true x86`, while `"c:\Program Files\Lua\Lua\5.4.4\bin\lua.exe" -e "print(1 << 32 == 0, 1 << 64 == 0, os.getenv(\"PROCESSOR_ARCHITECTURE\"))"` outputs `false true AMD64` (so it behaves the same). – CristiFati Apr 19 '22 at 14:19
  • Then both of your lua.exe files are 64-bit. The code is CORRECT. Your analysis is INCORRECT. – Jonathan Cohler Apr 20 '22 at 18:56
  • It's a simple mathematical fact. Bitwise shift operations discard bits as they "fall off" either end. So if you left shift a 1 by 32 bits it gives you 0 if you are using 32-bit integers. But 1<<32 does not equal 0 if you are using 64-bit integers. Furthermore, the provided function will also continue to work correctly even if you have a 128-bit LUA, because then 1<<64 will not be equal to 0 either. – Jonathan Cohler Apr 20 '22 at 19:11
  • If both were 64bit, then the 3rd item they output would also be the same wouldn't it? That's precisely why I put it there. But it isn't. – CristiFati Apr 21 '22 at 07:48
  • What are you even talking about? "the 3rd item they output"??? What "3rd item"? What is "they"? What "output"? Can you speak in plain/clear English please? – Jonathan Cohler Apr 22 '22 at 11:19
  • The function bits() which I gave above returns the numbers "32" on 32-bit LUA, "64" on 64-bit LUA, and boolean false, if someday there is a 128-bit LUA. It is absolutely CORRECT. Please stop with the incoherent babble here, and if you want to comment, say something that is CLEAR, SPECIFIC, and CORRECT. – Jonathan Cohler Apr 22 '22 at 11:22
  • Obviously there's a communication issue here (I didn't find a (good) way to explain to you). I posted 2 Lua runs, each outputting 3 items. The point is that your function will return 64 even for 32bit Lua. First I tested with my builds (https://github.com/CristiFati/Prebuilt-Binaries/tree/master/Lua), but then also with the ones from https://sourceforge.net/projects/luabinaries/files/5.4.2/Tools%20Executables, and it reproduces. It's all about that macro value when Lua was built - it's also possible for 64bit Lua to return 32 (but wouldn't make any sense). – CristiFati Apr 22 '22 at 23:44
  • WRONG. The function bits() above gives "32" on 32-bit LUA and "64" on 64-bit LUA as I have stated many times now. LUA will be 32-bit either because you are on a 32-bit machine or because you are on a 64-bit machine and you set the LUA_32BITS flag at LUA COMPILE TIME. In any case, at RUNTIME my bits() function above produces the CORRECT result at all times. You seem to be totally confused about the difference between whether a MACHINE is 32 or 64 bit and whether LUA is 32 or 64 bit. And the directory from which you run an EXE file has nothing to do with whether that program is 32 or 64-bit. – Jonathan Cohler Apr 24 '22 at 11:00
  • I assure you the confusion is not on my side (as I have quite some experience in that area, and many of my answers can prove that). The path sure doesn't have anything to do, (as it's just a guideline), but the *PROCESSOR\_ARCHITECTURE* does (check the other answers to this question). And again, it doesn't produce the correct result, as I tested with 32bit Lua executables (run on 64bit machine, but that doesn't make any difference). P.S.: capitalized words don't change the facts. – CristiFati Apr 25 '22 at 09:19
  • Perhaps you are using an old or corrupted version of LUA. Here is the LUA manual entry on bitwise shifts: https://www.lua.org/manual/5.4/manual.html#3.4.2 "3.4.2 – Bitwise Operators...Both right and left shifts fill the vacant bits with zeros...displacements with absolute values equal to or higher than the number of bits in an integer result in zero (as all bits are shifted out)." So 1<<32 on a 32-bit LUA returns 0. End of story. – Jonathan Cohler Apr 26 '22 at 22:31