Skip to content
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

Closed
tlawork opened this issue Mar 6, 2018 · 7 comments
Closed

old version fff to latest transition trouble due to extern "C" #45

tlawork opened this issue Mar 6, 2018 · 7 comments
Assignees
Labels
Projects

Comments

@tlawork
Copy link

tlawork commented Mar 6, 2018

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:

In function 'pid_t getpid()': declaration of 'pid_t getpid()' with C language linkage
conflicts with previous declaration 'pid_t getpid()' due to different exception specifications

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.

@tlawork
Copy link
Author

tlawork commented Mar 6, 2018

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 ...........

@meekrosoft
Copy link
Owner

Hi Todd,
Could you send me a cut down way to reproduce so I can investigate?
Thanks,
Mike

@tlawork
Copy link
Author

tlawork commented Mar 7, 2018

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.
ciscoduplication.tgz.zip

Unzip then CD to stub.
run the makefile and it should cd to _build folder and run the c++ command that fails.

@tlawork
Copy link
Author

tlawork commented Mar 13, 2018

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.

@meekrosoft
Copy link
Owner

Hi @tlawork - Sorry for the slow response, I'm traveling a lot these days...
Can you confirm that you can use the latest fff.h? Or by different direction, do you mean you have found a different testing solution?
Thanks!

@tlawork
Copy link
Author

tlawork commented Mar 14, 2018

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)

@wulfgarpro wulfgarpro added this to Needs triage in Triage! Nov 22, 2018
@wulfgarpro wulfgarpro moved this from Needs Triage to In Progress in Triage! Dec 14, 2018
@wulfgarpro wulfgarpro self-assigned this Dec 14, 2018
@wulfgarpro
Copy link
Collaborator

wulfgarpro commented Dec 14, 2018

@tlawork please try the latest version of fff; a lot of the extern C mess has gone.

I managed to fake getpid like so:

#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;
}

Triage! automation moved this from In Progress to Closed Dec 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Triage!
Closed
Development

No branches or pull requests

3 participants