alt Hacker News> 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.
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
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