-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
old version fff to latest transition trouble due to extern "C" #45
Comments
Here is more information. I added -E to the g++ compile and looked at the preprocessed output. Searching on getpid - I found the following is the FFF fake for getpid - and sure enough it is wrapped with extern "C" - yet I am running this on a CPP compiler and I made sure __cplusplus is set. So why is the fake for getpid wrapped with extern C???? or is that the design that all fakes are based on C? If so how do I make sure that the prototype declaration for the item (in this case getpid from unistd.h) is C-ized? _extern "C"{ typedef struct getpid_Fake { unsigned int call_count; unsigned int arg_history_len; unsigned int arg_histories_dropped; pid_t return_val; int return_val_seq_len; int return_val_seq_idx; pid_t * return_val_seq; pid_t return_val_history[(50u)]; int custom_fake_seq_len; int custom_fake_seq_idx; pid_t(*custom_fake)(void); pid_t(**custom_fake_seq)(void); } getpid_Fake; extern getpid_Fake getpid_fake; void getpid_reset(void); pid_t getp ........... |
Hi Todd, |
Sorry for the size of this - but in order to make this work for you without a lot of trouble - I precompiled, google test and the objects are left in this zip. Unzip then CD to stub. |
I am not going to close the issue - but we have decided to go a different direction (this error happened when we evaluated using Meson/Ninja instead of makefiles - and it brought to light that we had a few poorly written tests - which in turn brought to light that we have not been keeping up with the latest FFF sources.) So this will be a non-issue - if you want to close the issue you can - but you can keep it open if perhaps you think this might reveal a real issue. |
Hi @tlawork - Sorry for the slow response, I'm traveling a lot these days... |
by using the latest fff.h I get an error because the C++ test routine (specifically gtest) includes unistd.h as a c++ module, but FFF is faking it as a C module and the linker complains. We are trying to fake out the function getpid() which is defined in unistd.h By different direction - we are dropping our meson/ninja investigation and it was changing the build system that prompted this error - we do not get this error when using the older version of FFF so we are simply going to stick with the older version for now - so we are still on board using FFF - its very effective. TODDL (Cisco Systems) |
@tlawork please try the latest version of fff; a lot of the extern C mess has gone. I managed to fake #include <unistd.h>
#include <stdio.h>
#include <assert.h>
#include "fff.h"
DEFINE_FFF_GLOBALS;
FAKE_VALUE_FUNC(pid_t, getpid);
pid_t custom_getpid()
{
return 0xdeadbeef;
}
int main(void) {
getpid_fake.custom_fake = custom_getpid;
pid_t pid = getpid();
assert(getpid_fake.call_count == 1);
assert(pid == 0xdeadbeef);
return 0;
} |
I work at Cisco and we took a TDD class from James Grenning a while back and he introduced us to FFF. That was many years ago and we've been using an old version. We need to move to the latest because of our need for the ____VARARG fakes. However, in looking at the changes, there has been a lot of advancement since we pulled our copy - most notably there is a lot of changes regarding extern "C" declarations throughout dependent on #ifdef __cplusplus.
In particular, this is causing most of my existing unit tests to fail - probably because we took matters into our hands to address the placement of extern "C" - so as example, I have a unit under test in a C file that calls getpid. The test program is a CPP file and that is where FFF is included and getpid is faked.
On the call to
FAKE_VALUE_FUNC(pid_t, getpid)
it fails because of inconsistency:So my issue is - can you summarize what has changed in regard to extern C and how to handle that since the various upgrades through the years?
Should I be using extern C at all in my CPP test programs?
TODDL
Cisco Systems.
The text was updated successfully, but these errors were encountered: