cmocka 2.0 released

[Posted December 4, 2025 by jzb]

Andreas Schneider has announced version 2.0 of the cmocka unit-testing framework for C:

This release represents a major modernization effort, bringing cmocka firmly into the "modern" C99 era while maintaining the simplicity and ease of use that users have come to expect.

One of the most significant changes in cmocka 2.0 is the migration to C99 standard integer types. The LargestIntegralType typedef has been replaced with intmax_t and uintmax_t from stdint.h, providing better type safety and portability across different platforms. Additionally, we've adopted the bool type where appropriate, making the code more expressive and self-documenting.

Using intmax_t and uintmax_t also allows to print better error messages. So you can now find e.g. assert_int_equal and assert_uint_equal.

cmocka 2.0 introduces a comprehensive set of type-specific assertion macros, including `assert_uint_equal()`, `assert_float_equal()`, and enhanced pointer assertions. The mocking system has also been significantly improved with type-specific macros like `will_return_int()` and `will_return_float()`. The same for parameter checking etc.

LWN covered the project early in its development in 2013. See the full list of new features, enhancements, and bug fixes in cmocka 2.0 in the changelog.

to post comments

intmax_t

Posted Dec 4, 2025 15:25 UTC (Thu) by magfr (subscriber, #16052) [Link] (2 responses)

Given the well known problems with intmax_t (Primarily that it still is 64 bits because changing it would trigger an ABI break even though e.g. x86_64 have supported various types of int128 for the last ten years), what is their story about larger types?

The common consensus about intmax_t seems to be "Do not use it".

They also talk about C99, do they have a C26 story and e.g. _BitInt?

intmax_t

Posted Dec 4, 2025 23:06 UTC (Thu) by wahern (subscriber, #37304) [Link] (1 responses)

In fact, the C committee has been working for years on plans to deprecate and remove as much of it from the standard as possible. It some ways it's spurred a lot of activity around not only solving what intmax_t was originally intended to solve, but also to provide in-language features that could be used to move past intmax_t with minimal disruption, for example symbol aliasing and versioning.

An int_really_max_t that can’t be used in an ABI?

Posted Dec 7, 2025 5:04 UTC (Sun) by DemiMarie (subscriber, #164188) [Link]

What about providing an int_really_max_t that cannot be used in the type of any symbol with external linkage, or in the type of any struct it transitively depends on? The main use of intmax_t is as a type to cast to, especially in static assertions and similar.