2 ms·

Nethack embeds Lua 5.4.8, so you don't need it installed from a distribution's package manager. As long as your system can build C99* it can build Lua. And give

Nethack embeds Lua 5.4.8, so you don't need it installed from a distribution's package manager. As long as your system can build C99* it can build Lua. And given that Nethack 5.0.0 is C99, this dependency is not reducing portability any further. * Lua has a LUA_USE_C89 flag so it may be more portable than Nethack 5.0.0 at this point.

troad 5mo ago
> LUA_USE_C89 How much functionality/performance does one lose with this flag? Genuine question, I don't know. If C89 and C99 were equally performant/functional, it would seem logical to just target C89 (since any C99 compiler should be able to compile C89 too). There must be some reason it's a flag.
- archargelod 5mo ago
  I downloaded a Lua 5.4.8 source tarball and checked all the uses of LUA_USE_C89 (manually, without AI): luaconf.h:50-655 - windows builds always use C89 (quote: "broadly, Windows is C89") - in C99 Lua uses 'strtod' and 'sprintf' for hex number conversions. Otherwise, Lua provides its own implementation. - no math function variants with l_ and f_ prefixes in C89 - optional lua_KContext type is not available with C89 llimits.h:79 - type definition C99: uintptr.t vs C89: size_t llimits.h:184 - in C99 or GCC Lua has a pragma for inlining functions, otherwise it's macro'ed to nothing lmathlib.c:176 - math_log has an additional optimization in C99 if (base == l_mathop(2.0)) res = l_mathop(log2)(x); else lmathlib.c:285 - LUA_RAND32 define might fail to find 64-bit type (comment says it's for testing) loslib.c:36 - `strftime()` only supports one-char options in C89 lprefix.h:14 - no _XOPEN_SOURCE with C89 (POSIX/XSI stuff) - no _LARGEFILE_SOURCE with C89 (manipulation of large files in gcc and other compilers) both of these defines don't appear anywhere else in Lua source code
  - troad 5mo ago
    Thank you for looking through that; that's very interesting and helpful.

troad 5mo ago

> LUA_USE_C89 How much functionality/performance does one lose with this flag? Genuine question, I don't know. If C89 and C99 were equally performant/functional, it would seem logical to just target C89 (since any C99 compiler should be able to compile C89 too). There must be some reason it's a flag.

archargelod 5mo ago
I downloaded a Lua 5.4.8 source tarball and checked all the uses of LUA_USE_C89 (manually, without AI): luaconf.h:50-655 - windows builds always use C89 (quote: "broadly, Windows is C89") - in C99 Lua uses 'strtod' and 'sprintf' for hex number conversions. Otherwise, Lua provides its own implementation. - no math function variants with l_ and f_ prefixes in C89 - optional lua_KContext type is not available with C89 llimits.h:79 - type definition C99: uintptr.t vs C89: size_t llimits.h:184 - in C99 or GCC Lua has a pragma for inlining functions, otherwise it's macro'ed to nothing lmathlib.c:176 - math_log has an additional optimization in C99 if (base == l_mathop(2.0)) res = l_mathop(log2)(x); else lmathlib.c:285 - LUA_RAND32 define might fail to find 64-bit type (comment says it's for testing) loslib.c:36 - `strftime()` only supports one-char options in C89 lprefix.h:14 - no _XOPEN_SOURCE with C89 (POSIX/XSI stuff) - no _LARGEFILE_SOURCE with C89 (manipulation of large files in gcc and other compilers) both of these defines don't appear anywhere else in Lua source code
- troad 5mo ago
  Thank you for looking through that; that's very interesting and helpful.