Add simpler/semi-automatic unit test handling for pointer returns from stubs

[jphickey]

Is your feature request related to a problem? Please describe. For implementation functions which return some form of int32, the stub generator and default handler automatically makes this return 0 if nothing sets up anything else. The framework also provides a common method to provide alternate values. This int32 return was singled out because it is very common across OSAL, CFE, PSP, and apps.

The next most common return type (aside from void) is probably a pointer value. But this is not handled automatically, the user is required to provide a handler function just to be able to use the stub at all - even just to get it to return NULL. Furthermore there is no common method to get any other return value either.

Currently on a 64-bit platform one gets an error if attempting to use a generated stub "out of the box" because the framework sees a return type of size 8 which it refuses to translate from the int32 status value.

Describe the solution you'd like Expand the automatic/int32 return paradigm to pointer returns. Note on a 32-bit platform this probably already happens implicitly, since a pointer an an int32 are probably the same size, and "0" can be easily translated to NULL.

This is just two things:

• Provide equivalent of UT_SetDefaultReturnValue() and UT_SetDeferredRetcode() but for pointers, so tests can have a common method to register a pointer return.
• If the handler/hook does not set a return pointer/override, then grab the pointer from the registered value if its was set, or return NULL (basically the same as is done for int32 currently).

Describe alternatives you've considered Leave as-is where tests must always implement a custom handler for every function that returns a pointer.

Additional context Noted when developing CF unit tests, there are a number of FSW functions that return pointers, and it would be a good timesaver if one could simply run "generate_stubs" and use the stubs immediately as-is. While this is true for integer return codes, functions returning pointers all require extra work in order to use the generated stubs.

Requester Info Joseph Hickey, Vantage Systems, Inc.

[jphickey]

In theory this could also be done for integer return values of sizes smaller than 32-bits as well. Currently this also requires a custom handler, but for most any integer return value, it is only a matter of translating the integer value to the smaller size for return.

Basically, the more things that just work out of the box after running generate_stubs.pl, the better. Pointers and smaller return integers are two low-hanging fruits here.