Accessing static Data and Functions in Legacy C — Part 1

Posted on by

And a Happy Leap Year Bug

It’s a new year; last year was a leap year; so the quadrennial reports of leap year bugs are coming in. Apologies are in the press from Apple, TomTom, and Microsoft. Trains we stopped from running in China. Somehow calling them glitches seems to make it someone else’s fault, something out of their control. How long have leap years been around? Julius Caesar introduced Leap Years in the Roman empire over 2000 years ago. The Gregorian calendar has been around since 1682. This is not a new idea, or a new bug.

I’m going to try to take one excuse away from the programmers that create these bugs by answering a question that comes up all the time, “How do I test static functions in my C code?”

In code developed using TDD, static functions are tested indirectly through the public interface. As I mentioned in a this article TDD is a code rot radar. It helps you see design problems. Needing direct access to hidden functions and data in C is a sign of code rot. It is time to refactor.

But what about existing legacy code that has statics? It is probably way past the time for idealism and time for some pragmatism. In this article and the next, we’ll look at how to get your code untouched into the test harness and access those pesky static variables and functions.

If you don’t mind touching your code, you could change all mentions of static to STATIC. Then using the preprocessor, STATIC can he set to static during production and to nothing for test, making the names globally accessible. In gcc you would use these command line options

  • For production builds use -dSTATIC=static
  • For unit test builds use -dSTATIC

Let’s look at two options that, at least for access to statics, you will not have to touch your code to get it under test. First is #include-ing your .c in the test file. In the next article we’ll build a test adapter .c that give access to the hidden parts.

We are going to revisit code that is similar to the original code responsible for the Zune Bug. I rewrote the code to avoid attracting any lawyers but it is structured similarly to the original Zune driver, complete with static data and functions that must be correct for the function to work.

The header file provides a data structure and initialization function for figuring out the information about the date. Here is the header:

typedef struct Date
{
    int daysSince1980;
    int year;
    int dayOfYear;
    int month;
    int dayOfMonth;
    int dayOfWeek;
} Date;
 
void Date_Init(Date *, int daysSince1980);
 
enum {
    SUN = 0, MON, TUE, WED, THU, FRI, SAT
};
 
enum {
    JAN = 0, FEB, MAR, APR, MAY, JUN,
    JUL, AUG, SEP, OCT, NOV, DEC
};

Date_Init populates the Date instance passed in. Ignoring the fact that I can probably fully test this by rigging the daysSince1980, and inspecting the contents of the resulting Date structure, we are going to see how we can directly test the hidden functions and data.

Date_Init has three hidden helper functions.

void Date_Init(Date* date, int daysSince1980)
{
     date->daysSince1980 = daysSince1980;
     FirstSetYearAndDayOfYear(date);
     ThenSetMonthAndDayOfMonth(date);
     FinallySetDayOfWeek(date);
}

Date_Init is the tip of the iceberg. All the interesting stuff is happening in the hidden data and functions:

#include "Date.h"
#include <stdbool.h>
 
enum
{
    STARTING_YEAR = 1980, STARTING_WEEKDAY = TUE
};
 
static const int nonLeapYearDaysPerMonth[12] =
{ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };
 
static const int leapYearDaysPerMonth[12] =
{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };
 
static bool IsLeapYear(int year)
{
    if (year % 400 == 0)
        return true;
    if (year % 100 == 0)
        return false;
    if (year % 4 == 0)
        return true;
    return false;
}
 
static int GetDaysInYear(int year)
{
    if (IsLeapYear(year))
        return 366;
    else
        return 365;
}
 
static void FirstSetYearAndDayOfYear(Date * date)
{
    int days = date->daysSince1980;
    int year = STARTING_YEAR;
    int daysInYear = GetDaysInYear(year);
 
    while (days > daysInYear)
    {
        year++;
        days -= daysInYear;
        daysInYear = GetDaysInYear(year);
    }
 
    date->dayOfYear = days;
    date->year = year;
}
 
static void ThenSetMonthAndDayOfMonth(Date * date)
{
    int month = 0;
    int days = date->dayOfYear;
    const int * daysPerMonth = nonLeapYearDaysPerMonth;
    if (IsLeapYear(date->year))
        daysPerMonth = leapYearDaysPerMonth;
 
    while (days > daysPerMonth[month])
    {
        days -= daysPerMonth[month];
        month++;
    }
    date->month = month + 1;
    date->dayOfMonth = days;
}
 
static void FinallySetDayOfWeek(Date * date)
{
     date->dayOfWeek =  ((date->daysSince1980-1)+STARTING_WEEKDAY)%7;
}
 
void Date_Init(Date* date, int daysSince1980)
{
     date->daysSince1980 = daysSince1980;
     FirstSetYearAndDayOfYear(date);
     ThenSetMonthAndDayOfMonth(date);
     FinallySetDayOfWeek(date);
}

Let’s say you want to check the days per month vectors. You might want to write a test to check the months against the handy poem we use here in the US: Thirty days, has September, April, June and November; all the rest have thirty-one, except for February. It has 28 except in leap year it has 29.

If you started by writing this test…

TEST(Date, sept_has_30_days)
{
    LONGS_EQUAL(30, nonLeapYearDaysPerMonth[SEP]);
}

… you get this error:

DateTest.cpp:41: error: 'nonLeapYearDaysPerMonth' was not declared in this scope

Let’s get access to the hidden statics in the test case by including Date.c instead of Date.h in DateTest.cpp. The full test case file looks like this now:

#include "CppUTest/TestHarness.h"
 
extern "C"
{
#include "Date.c"
}
 
TEST_GROUP(Date)
{
};
 
TEST(Date, sept_has_30_days)
{
    LONGS_EQUAL(30, nonLeapYearDaysPerMonth[SEP]);
}

With a little refactoring days per month vectors can be checked like this:

#include "CppUTest/TestHarness.h"
 
extern "C"
{
#include "Date.c"
}
 
TEST_GROUP(Date)
{
    const int * daysPerYearVector;
 
    void setup()
    {
        daysPerYearVector = nonLeapYearDaysPerMonth;
    }
 
    void itsLeapYear()
    {
        daysPerYearVector = leapYearDaysPerMonth;
    }
 
    void CheckNumberOfDaysPerMonth(int month, int days)
    {
        LONGS_EQUAL(days, daysPerYearVector[month]);
    }
 
    void ThirtyDaysHasSeptEtc()
    {
        CheckNumberOfDaysPerMonth(SEP, 30);
        CheckNumberOfDaysPerMonth(APR, 30);
        CheckNumberOfDaysPerMonth(JUN, 30);
        CheckNumberOfDaysPerMonth(NOV, 30);
 
        CheckNumberOfDaysPerMonth(OCT, 31);
        CheckNumberOfDaysPerMonth(DEC, 31);
        CheckNumberOfDaysPerMonth(JAN, 31);
        CheckNumberOfDaysPerMonth(MAR, 31);
        CheckNumberOfDaysPerMonth(MAY, 31);
        CheckNumberOfDaysPerMonth(JUL, 31);
        CheckNumberOfDaysPerMonth(AUG, 31);
    }
 
    void ExceptFebruaryHas(int days)
    {
      CheckNumberOfDaysPerMonth(FEB, days);
    }
};
 
TEST(Date, non_leap_year_day_per_month_table)
{
    ThirtyDaysHasSeptEtc();
    ExceptFebruaryHas(28);
}
 
TEST(Date, leap_year_day_per_month_table)
{
    itsLeapYear();
    ThirtyDaysHasSeptEtc();
    ExceptFebruaryHas(28);
}

You have access to all the hidden stuff, so you can write the test for the static functions: IsLeapYear(), GetDaysInYear(), FirstSetYearAndDayOfYear(), ThenSetMonthAndDayOfMonth(), and FinallySetDayOfWeek().

If Date been an abstract data type, with its data structure hidden in the .c file, the tests would all have access to structure members hidden from the rest of the world.

There is a downside to this approach, which probably does not matter in this case, but could in others. You can only have one test file that can include a given .c file. In the next article we’ll solve that problem.

Have you heard of any interesting leap year bugs? Did you prevent your own?

11 thoughts on “Accessing static Data and Functions in Legacy C — Part 1”

  1. How is this different to testing private methods? With a TDD approach it’s possible you could have tested everything through Date_Init but let’s just say you couldn’t. Wouldn’t it be better to split up date.c and perhaps make a separate date_calculations.h with the functions available and testable through that? Just trying to figure out if this is terribly different to my OO thinking

  2. Hi Geoff

    It is the same as testing private methods. ‘static’ in c is file scope.

    If I was doing TDD, as mention in the article, the need to access statics in test cases would be a code/test smell. It would be a warning bell telling me to refactor.

    But this is a legacy code technique. I’d like to get some tests in place without changing anything. This is not always possible, but this technique gives one more way to get legacy c under test.

    I agree with you that splitting it is what you would eventually do, though it may be a bad idea to do it before there are some tests in place. I should probably find some code that is a bigger mess for the example, but then it would be too big for a concise article 🙂

    Thanks for the conversation.

  3. Your second technique here, including the c file instead of the header, couldn’t be used directly in c++ though, could it? This methods would still be private, and you could not access them. But the first technique could have been used, by doing:

    #define private public

    before including the header file in your test file. It is freakishly ugly, but would give you the same result as using -dSTATIC in your tests. At least a way you can start making tests, so you hopefully can refactor your class so you don’t need that ugly hack any more.

  4. Martin, you are right. Including the source in the test does not overcome C++ visibility. Define private to be public is an option, and as you say, temporary until you clean things up.

    Another alternative in C++ is making some things protected that you need access to and subclassing to gain access.

  5. Pingback: Accessing static Data and Functions in Legacy C — Part 2 | James Grenning’s Blog

  8. Hi James,
    I have a huge legacy code base(written mostly in C) which I want to test. Is it possible to test that code using CppUTest ,since my code uses gcc as a coppiler and CppUTest requires g++m as a compiler. I can not change the compiler for my code base because it will create a cascading effect due to dependencies. Is there a way to compile and link the test files using gcc as a compiler.
    Thanks

  9. Hi James,
    I have a huge legacy code base(written mostly in C) which I want to test. Is it possible to test that code using CppUTest ,since my code uses gcc as a compiler and CppUTest requires g++ as a compiler. I can not change the compiler for my code base because it will create a cascading effect due to dependencies. Is there a way to compile and link the test files using gcc as a compiler.
    Thanks

  10. Hello Arunesh

    CppUTest requires a C++ compiler. There are other test harnesses, but C vs C++ for a test harness is probably the least of your worries.

    Getting your code into a test harness is a challenge, but gets easier with each new file brought under test. Here is an article describing a process that provides a step-by-step process. https://wingman-sw.com/articles/get-your-legacy-c-into-a-test-harness

    You really want to start managing those dependencies. BTW, your C code is still compiled with the C compiler, unless you are using one of these #include the C file techniques.

    Hope that helps, James

  11. Thanks this was a good read.

    Just an idea that might save a lot of hair pulling months down the track:
    One might prefer to use a name like STATIC_FUNCTION rather than just STATIC for the macro to open up access to module-private functions during tests.

    (It just might prevent someone accidentally using STATIC for a variable inside a function, causing radically different behaviour between test runs and production runs.)

Leave a Reply

Your email address will not be published. Required fields are marked *

Be gone spammers * Time limit is exhausted. Please reload the CAPTCHA.