Including "standard headers" in mock files. #804
Comments
|
Oops, I attached this Issue to Ceedling instead of CMock. Please, move it over. |
|
Originally neither Unity nor CMock had lib dependencies other than setjmp/longjmp and that was intentional. Over time, some of the basic standard library usage has crept its way into both projects. In Unity, we've been very careful to make sure that there is always an alternative way to do it (Each standard library include is optional in Unity, including setjmp/longjmp. The effect of disabling a standard header just comes with additional steps the person building the test environment is responsible for. We feel like this is a good way to run things... where people can take advantage of the options when they're around, but still make good use of the tool when they're not. This has been the goal for CMock, but (as you've notice) we haven't been as effective in keeping up with the "optional" portion of this. I agree we should get back to that. Specifically (and this is partially notes for myself or whoever tackles this issue soon):
|
I've updated my PR and added tests: ThrowTheSwitch/CMock#454 |
When mocking a file, the cmock_generator includes first <string.h>, <stdlib.h> and possibly <setjmp.h> and then "cmock.h" and the mocked headers, etc.
This causes problems with our project. We're working on low-level, kernel/hypervisor software, and we define our own standard header files, since libc or a unix kernel is not available. I'd guess that's the case for most microcontroller code: there are libraries providing their own headers.
But in this particular case, we are mocking parts of the hypervisor itself, which provides the string.h and stdlib.h, etc.
So what happens, is that string.h includes amongst other files,
src/nkern/common/core/nktypes.hitself; therefore when we include the mocked version, mock_nktypes.h, we get duplicate declarations (no problem they're compatible), but in case of inlines, we get duplicate definitions!First, I would object on principle on the need for
string.handstdlib.hin the generated mock code. Evensetjmp.hshould not be directly needed by the mock code (it's used in the unity module to implement tests fornoreturnfunctions).The only occurence I see, is
memset. Amock_memsetcould be provided bycmock.h.But more fundamentally, as mentionned above, in a lot of projects, standard libraries don't come from libc and an underlying posix kernel. If they're available, they're not the host (the testing host) libraries. So this should preclude their use entirely in the generated mock code.
The text was updated successfully, but these errors were encountered: