You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be really nice if cmock created expect style functions for header declared variables as well as functions. Is creating shim "setter" functions like above the only way to validate this kind of behavior?
Before someone tells me that providing direct access to vars is bad form and I should be providing api function all the time: This is not a pattern that I use frequently, the one place where it crops up is where the var in question is actually a representation of a hardware register declared in some chip support header that gets automagically defined by the compiler. Specifically I'm working on a PIC32 that requires sequentially writing multiple values to a "SYSKEY" register in order to unlock writing to certain other configuration registers that are otherwise locked and readonly.
The text was updated successfully, but these errors were encountered:
Creating the expect-style interfaces (as you've proposed) wouldn't be hard. Unfortunately, the C language wouldn't allow us to intercept a direct variable assignment in the release portion of the code, so the generated hooks would be useless. We're confined in this case by the limits of the language.
Lets say I have a function in my module like this:
where x is declared in
some_file.h
as so:If I was only writing a single value, say just 5, I could use this pattern:
But how can I check that it was set to both 5 AND 6 consecutivly? If "some_file.h" provided a setter function instead of direct var access like:
Then I could do:
It would be really nice if cmock created expect style functions for header declared variables as well as functions. Is creating shim "setter" functions like above the only way to validate this kind of behavior?
Before someone tells me that providing direct access to vars is bad form and I should be providing api function all the time: This is not a pattern that I use frequently, the one place where it crops up is where the var in question is actually a representation of a hardware register declared in some chip support header that gets automagically defined by the compiler. Specifically I'm working on a PIC32 that requires sequentially writing multiple values to a "SYSKEY" register in order to unlock writing to certain other configuration registers that are otherwise locked and readonly.
The text was updated successfully, but these errors were encountered: