Use of C89 vs C99
Roger Leigh
This has likely been discussed previously, but I would like to ask why
the project is using C89 as a baseline, which is now rather long in the
tooth; even C99 is 27 years old at this point (I've been using it for
over 25 years since GCC first added support for it). Even in the
embedded world, which is notoriously slow to adopt new things, C99 has
been de rigour for well over a decade, if not longer.
The reason for bringing it up is that I've repeatedly run into problems
with the codebase when cross-compiling, usually for 32-bit ARMv7 or v8,
but there are also a host of papercuts when using Lua on regular systems
as well.
* luaconf.h goes through a very complex amount of preprocessor logic to
determine type sizes, format strings etc. But the assumptions it makes
don't hold for all compilers and platforms and this can be subtly or
unsubtly wrong, leading to bad behaviour at runtime. Simply using the
C99 <stdint.h> sized types and <inttypes.h> format string macros would
result in guaranteed correct behaviour all of the time, and greatly
simplify things.
* lmathlib.c goes through some very complex contortions with LUA_RAND32,
Rand64/SRand64 and the 32-bit fallback l_uint32, which again could be
entirely removed and replaced with standard sized types from <stdint.h>,
i.e. uint64_t/int64_t with uint32_t as the fallback (if it's needed).
* Similarly there are C89 specialisations for a number of things which
are standard in C99.
Back in 2023 I developed a patchset for my own use which removed all C89
compatibility code and made C99 the baseline, including:
Use C99 integer types and format strings
Use C99 snprintf directly in luaconf.h
Replace all uses of l_sprintf with snprintf
Replace all uses of lua_strx2number with lua_str2number
Replace all uses of lua_number2strx with snprintf
Replace all uses of lua_pointer2str with snprintf
Remove C89 specialisation of l_mathop macro
Remove C89 specialisation of lua_str2number macro
Remove C89 specialisation of L_P2I macro
Unconditionally enable C99 specialisation of LUA_KCONTEXT macro
Remove C89 specialisation of l_inline macro
Remove existing uses of l_inline macro
Unconditionally enable C99 log2 support in math_log
Remove C89 specialisation of LUA_STRFTIMEOPTIONS macro
Update LUA_STRFTIMEOPTIONS for latest Windows options
Remove LUA_USE_C89 option
loslib: Correct strftime options on Windows
If there would be any interest in bringing any or all of these changes
into the Lua codebase, I would be happy to rebase these against the
5.5.0-beta release and submit them.
Note that the Windows strftime options used in Lua are outdated, and
current Windows supports most of the POSIX behaviour, which is why you
see this in the above changelist.
Kind regards,
Roger
Roger Leigh
[...]
> Back in 2023 I developed a patchset for my own use which removed all
[...]
> If there would be any interest in bringing any or all of these changes
> into the Lua codebase, I would be happy to rebase these against the
> 5.5.0-beta release and submit them.
>
the broken out patchset attached to this email or via git at:
https://gitlab.com/codelibre/lua/lua-releases/-/commits/5.5.0-beta-upstream-c99-baseline?ref_type=heads
(against the 5.5.0-beta release)
or
https://gitlab.com/codelibre/lua/lua-cmake/-/commits/5.5.0-c99-baseline?ref_type=heads
(CMake build). Used to check all changes are passing the testsuite on
Linux (Alpine, Ubuntu), FreeBSD and Windows.
https://gitlab.com/codelibre/lua/lua-cmake/-/pipelines/2013012672/builds
Now that Windows has gained decent C99 support with recent versions of
Visual C++, and includes snprintf, stdint, inttypes etc., it no longer
needs to build in C89 mode.
This removes a good bit of unnecessary incidental complexity from the
codebase which is almost certainly not required in the present day.
Hope this is potentially useful for people.
Kind regards,
Roger
Roberto Ierusalimschy
> project is using C89 as a baseline, which is now rather long in the tooth;
> even C99 is 27 years old at this point (I've been using it for over 25
> years since GCC first added support for it). Even in the embedded world,
> which is notoriously slow to adopt new things, C99 has been de rigour for
> well over a decade, if not longer.
with C99. But it would be helpful to hear what others have to say.
I fully agree that removing support for C89 would simplify the code
in lots of places.
-- Roberto
Родион Горковенко
--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/20250830181751.GA1044261%40arraial.inf.puc-rio.br.
Roberto Ierusalimschy
Andrey Dobrovolsky
1. The bunch of patches by Roger Leigh are great. I'm sure that
Windows users will appreciate them.
2. Lua's C89 compatibility is exciting.
3. Breaking C89 compatibility doesn't add anything new to Lua.
4. It's absolutely cool when someone has the freedom to choose the
compiler to use. I like tcc. Someone may prefer cproc. Another one may
even write his own compiler.
5. In the current state we have C89 compatible Lua sources and a bunch
of great patches to make the sources C99 compatible. What is to be
changed? I can propose promoting the patches more ,maybe at lua.org
Regards,
Andrew
сб, 30 серп. 2025 р. о 22:03 Родион Горковенко <rodio...@gmail.com> пише:
Andrey Dobrovolsky
Regards,
Andrew
сб, 30 серп. 2025 р. о 22:20 Andrey Dobrovolsky
<andrey.dobro...@gmail.com> пише:
Luau Project
> But it would be helpful to hear what others have to say.
> I fully agree that removing support for C89 would simplify the code
> in lots of places.
Opposed to others ( http://lua-users.org/lists/lua-l/2022-11/msg00028.html ), the Lua language is not a "single product" killing C89 support, because Lua versions up to 5.4 are going to stay available in the website.
Andrew Trevorrow
> But it would be helpful to hear what others have to say.
then make that the final version to support C89 and move to C99
in Lua 6.0 and onwards.
Andrew
Jason Lethbridge
I'm not against C99 per se but when it comes to old and/or niche
systems you're more likely to find a C89 compiler for it than a C99
one. If there isn't a C compiler for it then it will be easier to write
a C89 compiler for it first. Having Lua strictly depend on C99 features
would delay or maybe even be a blocker for porting Lua to those
systems.
My personal example would be the Open Watcom C compiler which is still
C89, but with a minimal patch it can cross compile Lua 5.4 for 8086 and
i386 CPUs and target operating systems like PC-DOS 2, OS/2, Windows 95,
and even a completely static Linux ELF binary.
If Lua 5.4 was already a C99 codebase this would have been much more
difficult as Watcom C and many other compilers don't have a C99 front-
end while Clang/GCC dropped their i386 back-end a long time ago (and
never had a 8086 one). There's been talk recently about dropping i486,
ia64, m32c etc... back-ends from Linux/GCC communities as well. It's a
problem that will only grow with time.
> > .
云风 Cloud Wu
>
> Among others, Microsoft Visual Studio C in not fully compatible
> with C99. But it would be helpful to hear what others have to say.
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
So, c11 would be a better choice than c99 as a baseline ?
I'm not against c99, but I also think c89 is cool and gives users more
choice in compiler selection,
for example, we can use any c++ compiler , which can compile c89 code as c++ .
--
http://blog.codingnow.com
sur-behoffski
>> This has likely been discussed previously, but I would like to ask why the
>> project is using C89 as a baseline, which is now rather long in the tooth;
>> even C99 is 27 years old at this point (I've been using it for over 25
I've been playing with a C code program that comes from early Unix.
Separately, I've been very impressed by Gerard Holzmann of JPL, and
in particular how they managed to pull off landing Curiosity on Mars
(over 3 million lines, mostly C). In particular, "software
inspections", which (I believe) IBM used to validate every line of
the Space Shuttle code, was infeasible by several orders of
magnitude to process every line of code in the Mars mission.
I believe Gerard was a principal author of some coding standards at
JPL, including the "Power Of Ten": Ten coding standards that were
*not negotiable* because bugs had occurred in field-deployed
products that would not have occurred if these standards had been
followed.
The JPL coding standards were enhanced/extended to accommodate
other items, notably MISRA standards for automotive/other real-time
safety-critical software.
See especially Holzmann's talk on "Mars Code":
https://www.youtube.com/watch?v=16dQLBgOwbE
----
Tying this back to C89/C99, the standards demanded C99, first with
all warnings as errors, and eventually even requiring -wpedantic.
Furthermore, the infrastructure use a variety of compilers and
other code validation tools. (Many of the tool-based items in the
2012 effort have since been incorporated into e.g. gcc-15.2, which
is the compiler I currently run on my development machine.)
----
In my project, I've tried following these standards, first
limiting myself to strict C89, but found myself needing to use
pragmas/escape mechanisms too often. Changing to strict C99 fixed
these edge cases.
So, in summary, I tried very hard to work with C89 compliance, but
eventually had to cave in and use C99 as a baseline. My vote is for
Lua to move to strict C99 compliance sometime in the next few years.
cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software
Родион Горковенко
> Not clear for what reason.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/CAN5FJ7eZcr0yFTU76dCNup1g42YCXKWi5biwN2CUuQbH0i04uA%40mail.gmail.com.
Andrey Dobrovolsky
> sticking with C89 requires some extra efforts (though comparatively minor) both for general language development
> and for users targeting some specific modern systems.
Lua C API only. Lua sources are compiled with the help of some
compiler into liblua. The user links her/his code with the help of the
corresponding headers. Maybe an example of extra efforts to be
performed from her/his side?
Regards,
Andrew
нд, 31 серп. 2025 р. о 08:23 Родион Горковенко <rodio...@gmail.com> пише:
Roger Leigh
Hi Roberto,
Regarding Microsoft Visual Studio/Visual C++. It's technically true that it is not fully C99 compliant. However, in practice it supports all of the C99 features which Lua would require, today, to drop C89 support.
I've been developing various open source projects with MSVC support over the years, starting with VS2008. My experience was that it only really became usable for C99 code with VS2015 which added <stdint.h> and <inttypes.h> and a conforming snprintf; earlier versions lacked the headers but had a non-standard snprint implementation (_snprintf). With VS2019 it gained some more C99 features, maybe some of the string formatting/parsing functions. So for all intents and purposes, with the patches proposed here, Lua will build with VS2022 (confirmed with local and CI testing), and it should also build with VS2019.
Regarding the comments in the thread you linked to (http://lua-users.org/lists/lua-l/2022-11/msg00026.html), the comments Viacheslav Usov made about Visual Studio match what I've said above since he is referring to VS2019 having the needed C99 support. For users who really need to build on older versions, it should be patchable to build back to VS2015 without much effort. IMO anything older than that, which is thoroughly obsolescent for out of support versions of Windows, isn't something that is justifiable for an open source project to spend any time supporting, not least of which are the effort and resources required to test all of these old versions.
Wilfred Nilsen made a comment about embedded systems using old C89 compilers. Historically this was certainly true. Today, I think almost all current parts will have a C99 toolchain provided. I have worked in this field the last 7 years, and I've yet to see a non-C99-conforming compiler. I've used GCC cross-toolchains, IAR (ARM, MSP430), Keil and other less common toolchains, and they all supported C99 without exception. Heck, IAR even supports C++17 with a full embedded C++ standard library, as do the GCC cross-toolchains. While there may still be some vendors who ship ancient compilers, they are a distinct minority, and I don't think it should be used as a justification for keeping Lua stuck on C89. Most parts which have sufficient FLASH and RAM to host a Lua environment will have a C99 toolchain available. One thing which is often lacking in these discussions is concrete detail. Which parts and which compilers are problematic? I acknowledge that such parts must exist, but I've never encountered them personally. I've used MCUs and APs from Atmel, Analog, Nordic, TI, ST and NXP, and never once encounted a problem with C99. And I've run Lua on quite a few of them ;-)
As an example of a previous C99 conversion I did for the libTIFF project in 2021, you might find the context and discussion interesting. This was done in two steps, initially optionally using the C99 headers and features if present, and then as a followup using them unconditionally. The two steps were due to use of Autoconf/CMake and would not apply to Lua--it was primarily for staging the changes for managing the migration, testing and review. I would have liked to have linked to some of the relevant mailing list discussion, but unfortunately the archives went offline for this period.
https://gitlab.com/libtiff/libtiff/-/merge_requests/185 (build system work and preparation; includes detailed toolchain information in the discussion, and built with Linux, Windows (VS2019, Cygwin and MinGW))
https://gitlab.com/libtiff/libtiff/-/merge_requests/205 (main conversion)
https://gitlab.com/libtiff/libtiff/-/merge_requests/?sort=created_date&state=merged&search=c99 (list of small followup changes to complete the migration)
In the patchset I attached I've done a similar migration, but not replaced internal types with standard types e.g. replacement of l_uint32 with uint32_t; there are a number of additional cleanups which could be done as a followup exercise.
Kind regards,
Roger
Berwyn Hoyt
Lourival Vieira Neto
--
Lourival Vieira Neto
Roberto Ierusalimschy
> with the codebase when cross-compiling, usually for 32-bit ARMv7 or v8, but
> there are also a host of papercuts when using Lua on regular systems as
> well.
>
> * luaconf.h goes through a very complex amount of preprocessor logic to
> determine type sizes, format strings etc. But the assumptions it makes
> don't hold for all compilers and platforms and this can be subtly or
Could you tell us exactly what problems you had?
-- Roberto
Wilfred Nilsen
> Wilfred Nilsen made a comment about embedded systems using old C89
> compilers.
the auto-generated code we rely on is only emitted for C99. Indeed,
there are still a few legacy embedded systems locked into C89, but by
2025, these cases will be rare and increasingly niche. For the vast
majority of MCUs, C99 toolchains are now standard, so the tradeoff makes
sense :-)
-Wilfred
Warner Losh
Roger Leigh
Yes, certainly. These are just what I have to hand I can recall this evening.
1. The first isn't a Lua problem, it's a bug in the printf implementation of GCC newlib-nano which omits "long long integer" formatting for code size reasons. If you build with the defaults, integers print out "%lld" as "ld" without the number:
random seeds: 1756670153, -2147481100
vs
random seeds: ld, ld
Nothing Lua can reasonably do with this, though basing the default upon e.g. "sizeof(void*)" would give you the native size.
2. The second relates to interoperability with other libraries and the host application.
With the GNU ARM Embedded toolchain (GCC 14.2) building for ARMv8m (Cortex-M33), we have the following typedefs:
uint8 -> unsigned char
uint16_t -> unsigned short
uint32_t -> unsigned long
uint64_t -> unsigned long long
and similarly for the signed variants of each. There is no use of "int" in the fixed-width types. However, if you were to use LUA_32BITS you would get:
#if LUA_32BITS /* { */ /* ** 32-bit integers and 'float' */ #if LUAI_IS32INT /* use 'int' if big enough */ #define LUA_INT_TYPE LUA_INT_INT #else /* otherwise use 'long' */
That is, the Lua 32-bit integer type and the application 32-bit integer type can mismatch. While they are the same size, they are not directly convertible. This then necessitates a lot of typecasts and this is especially problematic with -Wconversion -Werror. Incorrect use of casts could lead to unintentional narrowing. [It's equally annoying with size_t which is "unsigned int" and not uint32_t.]
This is again not strictly a Lua problem--it's an interoperability issue at the boundary between Lua and the host application, including any custom libraries it provides. This is fixable by setting LUA_INT_DEFAULT correctly. But because this is a platform-specific detail, it might then break when you build for a different board with a different processor!
But using the same standard sizes on both sides eliminates the problem entirely.
3. Related to (2), the reliance upon int/long/long long is ambiguous when we don't know what size these are. In quite a few places we are doing quite a bit of work bitshifting to determine how many bits we have to work with. This ambiguity is removed at a stroke by using the fixed-width integer types.
4. Correctness, robustness, safety and static analysis. This was touched on by another poster relating to the use of macros vs inline functions. I'm very interested in improvements which can improve all of these. While this wasn't part of the patchset I sent, it's really doing the groundwork for potential future changes on top of it once C99 is available to be used. Inline functions bring type-safety, are reachable with a debugger, have no added overhead, and are better for static analysis of the codebase. Reducing the number of typecasts also makes it possible to spot problems which are masked, since the static analyser assumes any typecasts you add are correct. This becomes possible when the types are all standard known sizes. And the simplification of the codebase is also a benefit for this as well. Every need for an extra typecase, as mentioned above, is a potential bug which is most likely hidden from static analysis.
Regarding conversions, I actually build Lua with C++17 for the increased stringency around numerical conversions (-DLUA_LANGUAGE_SUPPORT=CXX with the CMake build). And run inline static analysis:
The Lua codebase is of very high quality, so there aren't any serious warnings, but there are a number of suggestions. I had to hunt to find one (minor) potential problem (unreachable code). But if we have to make efforts to verify correctness, C99 is a small step along the way. Internally, I may well be using C++ features such as "constexpr" and "enum class" in addition to inline functions (which have better semantics in C++) to improve the headers and again make compile-time error checking more robust and static analysis more effective. This is likely a much more controversial set of changes to upstream, so I most likely won't do this unless it's wanted! But I can look at making them available for anyone who is interested.
Kind regards,
Roger
bil til
2. The second relates to interoperability with other libraries and the host application.
That is, the Lua 32-bit integer type and the application 32-bit integer type can mismatch. While they are the same size, they are not directly convertible. This then necessitates a lot of typecasts and this is especially problematic with -Wconversion -Werror. Incorrect use of casts could lead to unintentional narrowing. [It's equally annoying with size_t which is "unsigned int" and not uint32_t.]
3. Related to (2), the reliance upon int/long/long long is ambiguous when we don't know what size these are. In quite a few places we are doing quite a bit of work bitshifting to determine how many bits we have to work with. This ambiguity is removed at a stroke by using the fixed-width integer types.
Roger Leigh
>> I had to hunt to find one (minor) potential problem (unreachable code)
> I think you just found a false-positive. See attachment.
trigger if lua_Number is a double. It does trigger if lua_Number is a
float. The static analysis is dependent upon how Lua has been configured.
Kind regards,
Roger
Sainan
-- Sainan
rolf.kal...@kalbermatter.nl
long on the other side is typically ALWAYS 32bit as I would assume... I hope I am correct :).
Roberto Ierusalimschy
>
> uint16_t -> unsigned short
>
> uint32_t -> unsigned long
>
> uint64_t -> unsigned long long
>
> But using the same standard sizes on both sides eliminates the problem
> entirely.
in a software that aims portability the way Lua does. That is, even if
we moved to C99, we would not use any of these types in the code, but
instead would use either the int_leastN_t or int_fastN_t variants.
> 3. Related to (2), the reliance upon int/long/long long is ambiguous when
> we don't know what size these are. In quite a few places we are doing
> quite a bit of work bitshifting to determine how many bits we have to work
> with. This ambiguity is removed at a stroke by using the fixed-width
> integer types.
Moreover, the Lua API never uses long nor long long directly. It uses
'int' and lua_Integer (and corresponding unsigned). If you need/want,
it should be trivial to change luaconf.h to define lua_Integer to be
exactly the type you want it to be.
> 4. Correctness, robustness, safety and static analysis. This was touched
> on by another poster relating to the use of macros vs inline functions.
> I'm very interested in improvements which can improve all of these. While
> this wasn't part of the patchset I sent, it's really doing the groundwork
> for potential future changes on top of it once C99 is available to be
> used. Inline functions bring type-safety, are reachable with a debugger,
> have no added overhead, and are better for static analysis of the
> codebase. Reducing the number of typecasts also makes it possible to spot
> problems which are masked, since the static analyser assumes any typecasts
> you add are correct. This becomes possible when the types are all standard
> known sizes. And the simplification of the codebase is also a benefit for
> this as well. Every need for an extra typecase, as mentioned above, is a
> potential bug which is most likely hidden from static analysis.
it does not preclude you from using them in your code.
-- Roberto