An empirical analysis of c preprocessor use

Ernst, M.; Badros, Greg J.; Notkin, David

doi:10.1109/tse.2002.1158288

Cited by 174 publications

(140 citation statements)

References 16 publications

Supporting

Mentioning

139

Contrasting

Order By: Relevance

“…Such mistakes-and others like undeclared variables, unused variables, and null pointerscommonly occur when using conditional compilation. Indeed, despite their widespread usage to implement variabil- ity in SPLs, #ifdefs pollute the code, lack separation of concerns, and make maintenance tasks harder [8,20,21,27].…”

Section: Motivating Examplementioning

confidence: 99%

Intraprocedural Dataflow Analysis for Software Product Lines

Brabrand¹,

Ribeiro²,

Tolêdo³

et al. 2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Software product lines (SPLs) are commonly developed using annotative approaches such as conditional compilation that come with an inherent risk of constructing erroneous products. For this reason, it is essential to be able to analyze SPLs. However, as dataflow analysis techniques are not able to deal with SPLs, developers must generate and analyze all valid methods individually, which is expensive for non-trivial SPLs. In this paper, we demonstrate how to take any standard intraprocedural dataflow analysis and automatically turn it into a feature-sensitive dataflow analysis in three different ways. All are capable of analyzing all valid methods of an SPL without having to generate all of them explicitly. We have implemented all analyses as extensions of SOOT's intraprocedural dataflow analysis framework and experimentally evaluated their performance and memory characteristics on four qualitatively different SPLs. The results indicate that the feature-sensitive analyses are on average 5.6 times faster than the brute force approach on our SPLs, and that they have different time and space tradeoffs.

show abstract

Section: Motivating Examplementioning

confidence: 99%

Intraprocedural Dataflow Analysis for Software Product Lines

Brabrand¹,

Ribeiro²,

Tolêdo³

et al. 2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…Numerous studies discuss the negative effect of preprocessor usage on code quality and maintainability (e.g., Spencer & Collyer (1992); Krone & Snelting (1994); Favre (1995Favre ( , 1997; Ernst et al (2002); Adams et al (2008)). However, researchers have also explored different strategies to deal with these problems.…”

Section: Related Workmentioning

confidence: 99%

“…Many researchers have attempted analysis and rewrite systems for unpreprocessed C code (Aversano et al, 2002;Hu et al, 2000;Overbey & Johnson, 2009;Vidacs et al, 2004;Tartler et al, 2011;Garrido & Johnson, 2005;Baxter & Mehlich, 2001;Livadas & Small, 1994). For example, Ernst et al (2002) identify problematic patterns and quantify them in a large code base, Tartler et al (2011) search for code blocks that are dead in all feature configurations, and Hu et al (2000) use control flow graphs to analyze the inclusion structure of files. However, all these approaches aim not directly at improving program comprehension by developers, but form underlying mechanisms and can be used to build tools.…”

Section: Related Workmentioning

confidence: 99%

Do background colors improve program comprehension in the #ifdef hell?

et al. 2012

View full text Add to dashboard Cite

Software-product-line engineering aims at the development of variable and reusable software systems. In practice, software product lines are often implemented with preprocessors. Preprocessor directives are easy to use, and many mature tools are available for practitioners. However, preprocessor directives have been heavily criticized in academia and even referred to as "#ifdef hell", because they introduce threats to program comprehension and correctness. There are many voices that suggest to use other implementation techniques instead, but these voices ignore the fact that a transition from preprocessors to other languages and tools is tedious, erroneous, and expensive in practice. Instead, we and others propose to increase the readability of preprocessor directives by using background colors to highlight source code annotated with ifdef directives. In three controlled experiments with over 70 subjects in total, we evaluate whether and how background colors improve program comprehension in preprocessor-based implementations. Our results demonstrate that background colors have the potential to improve program This is the authors' version and intended for personal use only. Any other use may violate the copyright. comprehension, independently of size and programming language of the underlying product. Additionally, we found that subjects generally favor background colors. We integrate these and other findings in a tool called FeatureCommander, which facilitates program comprehension in practice and which can serve as a basis for further research.

show abstract

“…Perhaps the most used macro system today is the C preprocessor. Ernst et al present an empirical study that demonstrates numerous violations of safety rules when using the C preprocessor [6]. Furthermore, code-generation based on concrete syntax is widely used in web applications.…”

Section: Language-agnostic Unsafe Macro Systemsmentioning

confidence: 99%

“…Well encapsulated but unsafe macro systems lead to buggy target code. Notably, the C preprocessor operates on tokens, is not guaranteed to produce correct code, and C programs with macros consequently contain numerous errors [6]. Safe but tightly-integrated macro systems are limited to a prescribed combination of host and target languages and cannot be shared across languages.…”

Section: Introductionmentioning

confidence: 99%

Marco: Safe, Expressive Macros for Any Language

Lee

Grimm

Hirzel

et al. 2012

ECOOP 2012 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Macros improve expressiveness, concision, abstraction, and language interoperability without changing the programming language itself. They are indispensable for building increasingly prevalent multilingual applications. Unfortunately, existing macro systems are wellencapsulated but unsafe (e.g., the C preprocessor) or are safe but tightlyintegrated with the language implementation (e.g., Scheme macros). This paper introduces Marco, the first macro system that seeks both encapsulation and safety. Marco is based on the observation that the macro system need not know all the syntactic and semantic rules of the target language but must only directly enforce some rules, such as variable name binding. Using this observation, Marco off-loads most rule checking to unmodified target-language compilers and interpreters and thus becomes language-scalable. We describe the Marco language, its languageindependent safety analysis, and how it uses two example target-language analysis plug-ins, one for C++ and one for SQL. This approach opens the door to safe and expressive macros for any language.

show abstract

An empirical analysis of c preprocessor use

Cited by 174 publications

References 16 publications

Intraprocedural Dataflow Analysis for Software Product Lines

Intraprocedural Dataflow Analysis for Software Product Lines

Do background colors improve program comprehension in the #ifdef hell?

Marco: Safe, Expressive Macros for Any Language

Contact Info

Product

Resources

About