Browse Prior Art Database

A method of macro analyzing to increase code coverage

IP.com Disclosure Number: IPCOM000239441D
Publication Date: 2014-Nov-07
Document File: 6 page(s) / 128K

Publishing Venue

The IP.com Prior Art Database

Abstract

Programmers tend to make use of macros in codes in order to control branches at compiling time, which would result in great complexity of test. This article is to provide a method to do macro analysis automatically and increase test coverage consequently. The core idea is to build a graph indicating the relationship of macros and iterately transform all macros to expression only including predefined macros. Thus, programmers would get the combination of predefined macros which could lead specific code to be executed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 6

A method of macro analyzing to increase code coverage

#ifdef USE_STD_LIB #include

#else

#include

#endif

And with compiler option

The core idea is to generate a graphic to show relationships of macros, and then every macro could be transformed to a logic expression of all pre-defined macros.

#ifndef A

stmt1

#define A

#else

stmt2

#endif

#ifdef B

stmt3

#define C

#endif

#if defined(A) && defined(C)

A macro is a fragment of code which has been given a name. Whenever the name is used, it is replaced by the contents of the macro. Programmers tend to make use of macros in codes in order to enable or disable some statements based on compiling-time switch. Especially, with macros we can write platform-specific and environment-specific codes more easily.

-DUSE_STD_LIB

, we can choose which header file to use.

Another advantage of macros is that they're expanded and replaced in preprocessor so that it won't generate any binary code in the object file and have nothing to do with runtime performance.

However, macros add a further complication to test. Systems are becoming so large that there are too many macros in source code. To test some certain segment of code, tester need to figure out the whole logic of all macros and find out the combination of macros, and that's almost impossible. Furthermore, it's even more difficult to write cases to cover 100% of source code.

1



Page 02 of 6

#define D

#endif

#ifdef D

#undef C

#endif

#if defined(A) || defined(B)
stmt4

#endif

#ifdef C

stmt5

#endif

A graph could be generated according to the code above.

2



Page 03 of 6

Above is an instance for the generation of graph. Furthermore, we could use the graph to calculate the value of every macro.

A1 A0


A2 ~A1| A1= 1
B1 B0

C1 B1 | C0= B0| C0


D1 (A2& C1) | D0 = B0& C0& D0
C2 ~D1& C1= (B0| C0) & ~(B0& C0& D0) = 0

We could make use of the expressions to figure out what kind of predefined macro combination could generate the most coverage of test cases.

Since the macros would change during the process, a macro in different state is regarded as different macros, distinguished by a suffix showing how many times the macro has been defined or undefined. The predefined value is labelled 0. Since the headers are proceeded linearly, there won't be conflict.

If a defination of macro is bounded by anif-clause , it relies on all macros in the if-condition . Thus, we could build the graph of relationship. To calculate the macros, the last state of the macro should also be considered. There are two kinds of circumstances.

For #undef statement, the macro is defined as the value its last state if

     ~(Condition ) & Mn-1, where Condition stands for the condition to undefine M , else, it would be the value of its last state.

On the other hand, for #define statement, the macro would be defined if

     Condition | Mn-1 , where Condition stands for the condition to define M
, or keep its last state elsewise.

Then, we could just substitute all the macros with their latest state, and get an expre...