Hi, I've started with cmocka 2.0. The biggest change will be that uintmax_t will be used from stdint.h. Also there will be a lot of new assert functions. If you want to add features it is a good time to do that now. The plan is not to break the API with 2.0, however the ABI will change but it shouldn't be a problem for a unit testing library. Cheers Andreas
On Monday, 4 January 2021 23:51:03 CET Andreas Schneider wrote:
Hi,
I've started with cmocka 2.0. The biggest change will be that uintmax_t will be used from stdint.h.
Also there will be a lot of new assert functions. If you want to add features it is a good time to do that now.
The plan is not to break the API with 2.0, however the ABI will change but it shouldn't be a problem for a unit testing library.
The development takes place at: https://gitlab.com/cmocka/cmocka/
What about C89 compatibility? - Are you going to `ifdef` stdint? (I've been using https://github.com/silentbicycle/greatest but cmocka naturally has more features) Samuel Marks Charity <https://sydneyscientific.org> | consultancy <https://offscale.io> | open-source <https://github.com/offscale> | LinkedIn <https://linkedin.com/in/samuelmarks> On Tue, Jan 5, 2021 at 9:53 AM Andreas Schneider <asn@cryptomilk.org> wrote:
On Monday, 4 January 2021 23:51:03 CET Andreas Schneider wrote:
Hi,
I've started with cmocka 2.0. The biggest change will be that uintmax_t will be used from stdint.h.
Also there will be a lot of new assert functions. If you want to add features it is a good time to do that now.
The plan is not to break the API with 2.0, however the ABI will change but it shouldn't be a problem for a unit testing library.
The development takes place at:
https://gitlab.com/cmocka/cmocka/
_______________________________________________ cmocka-devel mailing list -- cmocka-devel@cmocka.org To unsubscribe send an email to cmocka-devel-leave@cmocka.org
On Tuesday, 5 January 2021 00:54:38 CET Samuel Marks wrote:
What about C89 compatibility? - Are you going to `ifdef` stdint?
cmocka already requires C99. However there is a cmocka_platform.h you can create to define types your platform doesn't provide like uintmax_t and then compile cmocka. C89? Really? I mean C99 is more than 20 years old now. There was enough time to implement it in the meantime ;-)
Cool, I might just do that. Yeah I know C89 is a bit extreme, but to ensure proper portability to OpenBSD, FreeBSD, NetBSD, Windows, Linux, macOS, and illumos, using C89 seems to be the path of least resistance. Samuel Marks Charity <https://sydneyscientific.org> | consultancy <https://offscale.io> | open-source <https://github.com/offscale> | LinkedIn <https://linkedin.com/in/samuelmarks> On Tue, Jan 5, 2021 at 6:16 PM Andreas Schneider <asn@cryptomilk.org> wrote:
On Tuesday, 5 January 2021 00:54:38 CET Samuel Marks wrote:
What about C89 compatibility? - Are you going to `ifdef` stdint?
cmocka already requires C99. However there is a cmocka_platform.h you can create to define types your platform doesn't provide like uintmax_t and then compile cmocka.
C89? Really? I mean C99 is more than 20 years old now. There was enough time to implement it in the meantime ;-)
On Tuesday, 12 January 2021 01:56:38 CET Samuel Marks wrote:
Cool, I might just do that. Yeah I know C89 is a bit extreme, but to ensure proper portability to OpenBSD, FreeBSD, NetBSD, Windows, Linux, macOS, and illumos, using C89 seems to be the path of least resistance.
All of the platforms you mention here support C99 ...
All platforms: yes All compilers: no. Most are just toy compilers, some are special (tcc) https://en.wikipedia.org/wiki/List_of_compilers#C_compilers In terms of which "mainstream" compilers FULLY support a C standard greater than C89, all of GCC, Clang, and I think Intel's oneAPI DPC++ / C++ Compiler also. But not MSVC. The default standard for Intel is C89 https://software.intel.com/content/www/us/en/develop/articles/c99-support-in... It doesn't appear that you can set the standard granularly for MSVC, https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-st... (except with Linux https://docs.microsoft.com/en-us/cpp/linux/prop-pages/c-cpp-linux?view=msvc-... ) But you can force C89 everywhere: https://docs.microsoft.com/en-us/cpp/build/reference/za-ze-disable-language-... With the caveat: https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-st...
It isn't possible to specify strict C89 conformance.
Also, AFAIK, C99 isn't fully implemented by MSVC. My reference for this is an in the docs for an older MSVC version, which is why I disclaim "AFAIK": https://docs.microsoft.com/en-us/previous-versions/hh567368(v=vs.140)?#c11-c... https://docs.microsoft.com/en-us/previous-versions/hh567368(v=vs.140)?#c99-_... When I write C code I like to ensure it is properly portable. Insofar as it's possible, the behaviour should be identical no matter the compiler, target OS, or host OS. Also I like to compare historic and current innovations, e.g., swapping out the malloc implementation, and profiling dis/advantaged result. Finally from an FFI perspective there are advantages in targeting C89, so that you can guarantee interoperability with the lowest version of whatever language is calling into C. Additionally the latest version (July 2020 release) of CFFI—a popular one for Python—doesn't support all of C99, but guarantees support for all of C89. That is why I target C89. Samuel Marks Charity <https://sydneyscientific.org> | consultancy <https://offscale.io> | open-source <https://github.com/offscale> | LinkedIn <https://linkedin.com/in/samuelmarks> On Thu, Jan 14, 2021 at 4:02 PM Andreas Schneider <asn@cryptomilk.org> wrote:
On Tuesday, 12 January 2021 01:56:38 CET Samuel Marks wrote:
Cool, I might just do that. Yeah I know C89 is a bit extreme, but to ensure proper portability to OpenBSD, FreeBSD, NetBSD, Windows, Linux, macOS, and illumos, using C89 seems to be the path of least resistance.
All of the platforms you mention here support C99 ...
On Thursday, 14 January 2021 06:39:33 CET Samuel Marks wrote:
All platforms: yes All compilers: no.
Most are just toy compilers, some are special (tcc) https://en.wikipedia.org/wiki/List_of_compilers#C_compilers
In terms of which "mainstream" compilers FULLY support a C standard greater than C89, all of GCC, Clang, and I think Intel's oneAPI DPC++ / C++ Compiler also. But not MSVC.
For MSVC not supporting C99 it compiles just fine with C99 features in use: https://gitlab.com/cmocka/cmocka/-/pipelines/241222132
The default standard for Intel is C89 https://software.intel.com/content/www/us/en/develop/articles/c99-support-in -intel-c-compiler.html
I do not plan to stop or reverting C99 features we already use in cmocka. We are already past that point since some years. Also 20 years to adopt C99 is enough time. If you require C89 then might be good idea to use a different unit testing framework. As I said I will not move backwards as we use C99 feature since years already. Andreas
I was more thinking feature guards, and yeah I agree it is crazy that modern compilers and popular FFI layers alike don't [fully] support a 22 year old C standard. However, this means that targetting the 31 year old C standard is the only genuinely portable [C] solution. I'll stick to the less feature rich [toy] greatest.h for now… On Thu, 14 Jan 2021, 4:58 pm Andreas Schneider, <asn@cryptomilk.org> wrote:
On Thursday, 14 January 2021 06:39:33 CET Samuel Marks wrote:
All platforms: yes All compilers: no.
Most are just toy compilers, some are special (tcc) https://en.wikipedia.org/wiki/List_of_compilers#C_compilers
In terms of which "mainstream" compilers FULLY support a C standard greater than C89, all of GCC, Clang, and I think Intel's oneAPI DPC++ / C++ Compiler also. But not MSVC.
For MSVC not supporting C99 it compiles just fine with C99 features in use:
https://gitlab.com/cmocka/cmocka/-/pipelines/241222132
The default standard for Intel is C89
https://software.intel.com/content/www/us/en/develop/articles/c99-support-in
-intel-c-compiler.html
I do not plan to stop or reverting C99 features we already use in cmocka. We are already past that point since some years. Also 20 years to adopt C99 is enough time.
If you require C89 then might be good idea to use a different unit testing framework. As I said I will not move backwards as we use C99 feature since years already.
Andreas
Hello Andreas, Great news! For me, cmocka's most important feature is its extensibility. To me, this means that cmocka needn't provide every conceivable assertion, but that it provides the building blocks to make them. For example, I'm thinking of - access to cmocka's diagnostic routines: cm_print_error, _fail, etc. - base functions to build on? As an example, here's how I implemented an assertion for approximate floating-point equality before one was available in cmocka: #define assert_double_equal(got, expected, rtol, atol) assert_double_equal_(got, expected, rtol, atol, __FILE__, __LINE__) void assert_double_equal_(double got, double expected, double rtol, double atol, const char * const file, const int line) { if (fabs(got - expected) < rtol * fabs(expected) || fabs(got - expected) < atol) return; cm_print_error("floating-point values not equal within tolerance: %g != %g (with rtol=%g and atol=%g)\n", got, expected, rtol, atol); _fail(file, line); } Currently, cm_print_error is not in the public header file. It's exported, though, so linking just works. But it feels wrong to use '_fail' in user code. Maybe a user-visible, "official" version would be a good idea? Kind regards Edward } On Mon, Jan 4, 2021 at 11:51 PM Andreas Schneider <asn@cryptomilk.org> wrote:
Hi,
I've started with cmocka 2.0. The biggest change will be that uintmax_t will be used from stdint.h.
Also there will be a lot of new assert functions. If you want to add features it is a good time to do that now.
The plan is not to break the API with 2.0, however the ABI will change but it shouldn't be a problem for a unit testing library.
Cheers
Andreas
_______________________________________________ cmocka-devel mailing list -- cmocka-devel@cmocka.org To unsubscribe send an email to cmocka-devel-leave@cmocka.org
On Tuesday, 5 January 2021 16:32:30 CET Edward Baudrez wrote:
Hello Andreas,
Hi Edward,
Currently, cm_print_error is not in the public header file. It's exported, though, so linking just works. But it feels wrong to use '_fail' in user code. Maybe a user-visible, "official" version would be a good idea?
I think we should provide more of those building blocks, I agree. I've also wrote assert functions for sockaddr in my projects :-) Andreas -- Andreas Schneider asn@cryptomilk.org GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
participants (3)
-
Andreas Schneider -
Edward Baudrez -
Samuel Marks