2 ms·
> 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/function
by 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 agoI 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 agoThank you for looking through that; that's very interesting and helpful.