Function pointer link stubs

Bas Vodde

Sep 13, 2008 — 1 min read

Last week been test-driving some C code again and found that not much people are familiar with the "function pointer link stub". This is an excellent technique in C to dynamically replace library calls without adjusting the library.

Imagine, you are working on some embedded software. You will have a couple of libraries that you use, but you won't link to it when unit testing. Instead you stub them out. But, a link stub cannot be adjusted on run-time, so how do you handle this? With... "function pointer link stubs".

The idea is simple. You stub out the library and your stub calls a function pointer when its set. When not set, it just returns success.

Here is some example code:

.h (in a library where we cannot change the header)

int aLibraryCallWeCannotChange(int param);

----------------
aLibraryStub.h

extern int (*aLibraryCallWeCannotChangeFp)(int param);

-----------------
aLibraryStub.c

int aLibraryCallWeCannotChange(int param)
{
if (aLibraryCallWeCannotChangeFp) aLibraryCallWeCannotChangeFp(param);
return 0;
}

int (*aLibraryCallWeCannotChangeFp)(int param) = NULL;

-------------------------
TestThatUsesLibrary.cpp

TEST_GROUP(blah)
{
void setup()
{
UT_PTR_SET(aLibraryCallWeCannotChangeFp, dynamicStubOfALibraryCall);
}
}

Now it is easy to place the code of your stub close to your tests and you will never have to change the linker stub code.

Empowered Product Team vs. LeSS Feature Team

Recently, while discussing with a potential client, I learned of their interest in adopting a Product Operating Model. This prompted me to study the concept in greater depth. It wasn’t my first encounter with Marty Cagan’s work; I had read his book Inspired long time ago and have

Requirement Areas are NOT around product modules

Baseline vs. change is an important distinction in product development. Missing that contributes to a common misguided practice in creating RAs (Requirement Areas) around product modules. Product module is about baseline, while RA is about change. Instead of creating RAs around product modules, we create RAs around product changes. Let’

Getting started

I have often been explaining how a LeSS adoption gets started on various occasions, so I decided to write it down as an article, not to avoid doing it any more - I will still do it as the interaction alongside it is irreplaceable - but to make it a

LeSS adoption without frameworks

I have advocated to balance framework focus with experiment focus in the use of LeSS. As the framework focus is already strong, I’d like to elaborate more on the experiment focus. Is it possible to adopt LeSS without adopting its frameworks? I think yes, as that is actually continuous

Read more

Empowered Product Team vs. LeSS Feature Team

Requirement Areas are NOT around product modules

Getting started

LeSS adoption without frameworks