[trynumber9]

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]

> 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]

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]

Thank you for looking through that; that's very interesting and helpful.