:treat_as: not working as expected

[Jakebluhm]

I created a very simple repo to explain this issue / confusion I have with the treat_as configuration parameter. Please see the link below:

https://github.com/Jakebluhm/cmock-issue/

I have one function in my example.c/.h file:

example.h:
int *const foo(float const *const self);

example.c:
int *const foo(float const *const self) { return self - 1; }

These types are unusual but are needed for a specific reason for embedded C code. The issue is that by default the mock version of this function's return value is changed, which causes Ceedling build errors. I want to use the treat_as to fix cmocks default behavior to leave the stub's return value as is.

The mocked version of the function is:
const int* foo(float const* const self) {...}

int *const gets converted to const int*
Why does this ^ happen? and how can I override this behavior?

The cmock stub's return value is different than the source stub and I want to use treat_as to fix this. Here is my configuration file that I use in a cmock CLI call to generate the mock for example.c/.h

cmock_config:

:cmock:
  :parse_dump: true
  :treat_as:
    'int *const': 'HELLO'

To run this example I am generating this mock with:
$ ruby {path to cmock}\cmock.rb -ocmock_config example.h

[Jakebluhm]

$ ceedling version
Welcome to Ceedling!
    Ceedling:: 0.31.1
       CMock:: 2.5.4
       Unity:: 2.5.4
  CException:: 1.3.3

[mvandervoord]

Hi.

So two things:

1. The :treat_as feature is only going to help by matching assertions to types... therefore it doesn't do anything with return values, just passed arguments.
2. Unfortunately you've run into a known bug with CMock. It's going to be fixed in the next major release, which will include an overhaul of how CMock manages types internally. At the moment, it attempts to standardize some usage of const int * vs const * int vs const * const int and so on. This "standardization" is wrong and it's the problem you're running into. I apologize, but at this moment there isn't a solution outside of defining a custom type to pass around which has the proper handling.

[Jakebluhm]

@mvandervoord I appreciate your attention on this. I'll keep an eye out for CMock v3.0.0 or a dev branch that is working on this issue.

Out of curiosity and maybe for others who have this issue and want to find a work around, could you point towards what script drives this behavior? Or is this a major overhaul that cannot be described simply?