Understanding Conditional Compilation Through Integrated Representation of Variability and Source Code

Christina Sixtus; David Baum; Lisa Vogelsberg; Ulrich Eisenecker

REVIEW 3 major objections 6 minor 28 references

Understanding Conditional Compilation Through Integrated Representation of Variability and Source Code

T0 review · 3 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A C-preprocessor-aware analytics tool lets developers toggle feature flags and watch which code entities disappear.

desk verdict A competent SPLC short-paper tool demo with a real prototype but a load-bearing 'complete' claim about Q2 that needs a ground-truth check before it can be taken literally. read the letter →

arxiv 1908.08375 v1 pith:3ZU7DOQS submitted 2019-08-20 cs.SE

David Baum , Christina Sixtus , Lisa Vogelsberg , Ulrich Eisenecker This is my paper · ORCID

classification cs.SE

keywords conditionalcompilationCpreprocessorfeatureflagssoftwareproductlinesvariabilityvisualizationvisualanalyticsTypeChef

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that the variability hidden in C conditional compilation can be made directly inspectable: a developer should be able to pick a set of feature flags and see exactly which functions, global variables, and complex types will exist in that variant. To that end it builds a tool pipeline that parses C with preprocessor awareness, stores the result as a graph, and renders it interactively so excluded entities become transparent. The concrete demonstration is BusyBox; toggling CONFIG_DESKTOP immediately shows how macro chains spread the flag's effect across 75 of 354 translation units. The paper's own standard of success is two questions: 'what does activating a feature do to program structure' and 'which elements exist under a given configuration'; it claims the second is already answered completely, and the first only partially because not every feature location is visually exposed yet.

What carries the argument

The load-bearing mechanism is a four-stage pipeline: TypeChef modified to serialize a variability-aware AST to XML, an jQAssistant plugin that ingests that XML into a Neo4j graph, the Getaviz visualization toolkit, and the Recursive Disk metaphor adapted to C. The Recursive Disk layout maps each translation unit to a gray disk, functions to blue segments with area proportional to lines of code, global variables to fixed-size yellow segments, and structs, enums, and unions to purple disks. This mapping is what lets a flag toggle be rendered as transparency rather than a textual search, and the graph is what lets entity-presence questions be answered by structure rather than by hand-tracing macros.

What would settle it

Take a C system such as BusyBox 1.18.5, run the TypeChef-to-graph pipeline, then for a set of flag configurations compile the system and count which functions, global variables, and complex types actually appear in the preprocessed translation units; any entity the tool marks as present but the preprocessed output omits, or vice versa, refutes the tool's claim that Q2 is answered completely.

Watch

Extended reading notes

Core claim

The central claim is that integrating variability information with source-code structure in one graph model makes preprocessor-based product lines comprehensible. The tool serializes TypeChef's variability-aware AST to XML, loads it through an jQAssistant plugin into a graph containing code entities, method calls, read/write accesses, features, and dependencies, and visualizes the graph with Getaviz's Recursive Disk metaphor. In the visualization, translation units are gray disks, functions are blue segments sized by lines of code, global variables are yellow segments, and structs, unions, and enums are purple disks. The user toggles feature flags in the FeatureExplorer UI; entities excluded by the C preprocessor become transparent, turning a configuration query into a visible structural comparison. The application to BusyBox 1.18.5 shows that this answers Q2 completely, while Q1 remains partially supported until feature-to-method highlighting is exposed in the interface.

Load-bearing premise

The tool's correctness rests on TypeChef's variability-aware parse: if it misreads or omits a preprocessor directive, macro-expanded branch, or feature reference, the visualization shows a different variant than the compiler would build.

Editorial extensions

If this is right

Developers can see every function, global variable, and complex type that could be part of any variant before choosing a configuration, giving a system-wide overview.
Selecting or deselecting feature flags updates the structure, so excluded entities become transparent and the effect of the flag is visible without jumping between source files.
A single feature flag such as CONFIG_DESKTOP, which reaches 75 of 354 BusyBox translation units through macros like ENABLE_DESKTOP, IF_DESKTOP, and IF_NOT_DESKTOP, is handled automatically.
The analysis runs without manual preprocessing and, on the reported setup, handles systems up to roughly four million lines of code, with the BusyBox graph generation taking about one day on a conventional notebook.
Q2 is claimed to be fully answered: for a given feature configuration, the tool can list which elements are present. Q1 is only partially answered because not all feature locations are yet visually detectable.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The same pipeline should transfer to any preprocessor-conditional system, not just product-line feature flags: platform-specific #ifdefs, compile-time debugging switches, and version guards would all become queryable graph structure rather than scattered directives.
Because the graph retains nested conditions and branch alternatives, it could be extended to search for dead-feature configurations, flag sets for which no entity remains, or to detect feature flags that affect no entity, without new parsing.
A testable extension would be to color translation units by variability density, the number of distinct flags guarding their entities, so feature-heavy modules stand out in the overview, a design choice the paper does not itself explore.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague — quick take: this is a short SPLC tool paper, not a research breakthrough. What's new is the integration: TypeChef's variability-aware AST serialized to XML, jQAssistant as the graph layer, and Getaviz's Recursive Disk visualization with interactive feature toggles for C conditional compilation. I'm not aware of another tool that gives this system-wide feature-configuration view of C code, and the design rationale is sensible. The BusyBox demo is a reasonable choice, and the paper is honest that Q1 is only partially answerable and that comparisons with existing tools are future work.

The thing to scrutinize is the Discussion claim that "Q2 can already be answered completely." That claim is load-bearing: if the extracted entity set under a feature configuration omits or misattributes anything, the tool's core value—tracing what enabling a flag affects—collapses. The completeness depends entirely on TypeChef capturing every relevant directive, macro expansion, and nested condition, and the paper gives no ground-truth validation of that extraction on BusyBox. TypeChef is known to handle only a subset of arbitrary C preprocessor constructs, and requirement (3) acknowledges that macros can affect feature detection. A simple brute-force preprocessing comparison would settle it, or at least a check on a few files with known presence conditions. Without that, "completely" is an overstatement.

Other soft spots: no user study, no baseline comparison, and no performance measurement behind "up to four million lines of code." Those are minor for a 4-page tool demo, and the authors explicitly list them as future work. The lack of an independent artifact is partly offset by the online demo and screencast, though the demo wasn't exercisable from the paper text. One caveat: the tool and Getaviz come from the same group, so the demo is self-referential; that's normal for tool papers, but it raises the bar for independent validation, which isn't met.

If I were refereeing, I'd accept with revisions asking for the Q2 completeness claim to be either downgraded to "demonstrated on this example" or backed by a ground-truth extraction check. The integration is real, the write-up is clear, and the topic is useful for people maintaining configurable C systems. It deserves a serious referee but not publication as is.

Referee Report

3 major / 6 minor

Summary. The paper presents an interactive visual analytics tool, built as an extension of Getaviz, for investigating conditional compilation in C source code. The tool uses TypeChef to parse C code without manual preprocessing, serializes the variability-aware abstract syntax tree to XML, and stores the result in a graph database via jQAssistant. The user interface visualizes all potentially compiled code entities using a Recursive Disk metaphor, lets the user toggle extracted feature flags, and updates the visualization by rendering excluded entities transparently. The authors illustrate the tool on BusyBox 1.18.5, showing the effect of the CONFIG_DESKTOP feature flag on several translation units. They claim the tool bridges the gap between feature models and concrete CPP-based implementations, that Q2 ('which elements are contained in the source code given a certain feature configuration') can already be answered completely, and that Q1 ('what effect does the activation of a feature have on the structure of a program') can be answered only partially. The paper is framed as a demonstration and reports no user study or quantitative evaluation.

Significance. If the central claims were established, the tool would fill a real gap: most existing variability visualizations operate at the feature-model level or require manual preprocessing, whereas this tool attempts to connect feature configurations directly to source-level entities in an integrated environment. The adaptation of the Recursive Disk metaphor to C translation units is a sensible design choice, and the integration of TypeChef, jQAssistant, and Getaviz is a plausible pipeline that avoids manual preparation steps. The paper includes an online demo and a screencast, which are valuable for a tool-demo venue. However, the significance is limited by two issues: the completeness of Q2 depends on an unvalidated assumption about TypeChef's extraction accuracy, and the usefulness claims rest solely on the authors' own BusyBox demonstration. The contribution is best viewed as a prototype and a design proposal that needs stronger evidence before the stronger claims are acceptable.

major comments (3)

[§3, §6] The paper states in §6 that Q2 'can already be answered completely', but this claim is not supported by the evaluation in §5. The completeness of the answer depends on the TypeChef variability-aware AST, serialized to XML, containing every relevant conditional compilation directive, macro expansion, nested condition, and feature reference. No ground-truth check is reported: there is no comparison with brute-force preprocessing for a set of configurations, no enumeration of expected entity sets, and no error analysis of TypeChef's known limitations for arbitrary preprocessor constructs. In addition, requirement (3) in §3 acknowledges that macro expansions can influence feature detection and location, yet no evidence is given that expanded macros preserve the presence conditions needed for the visualization. I ask the authors to add a validation on the BusyBox example, for instance by preprocessing several concrete configurations and comparing the entities shown by the tool with those actually compiled, and to state the limitations of TypeChef that remain.
[§1, §5, §7] The abstract and conclusion claim that the tool 'simplifies tracing and understanding' the effect of enabling or disabling feature flags, and §5 states that it 'improves the developers understanding' of the resulting structure and behavior. The only evidence is the authors' own BusyBox demonstration, consisting of screenshots and a screencast. There is no user study, no baseline comparison with existing tools or manual inspection, and no task-based or time-based measurement. The claim as stated is therefore not supported. The authors should either add a small comparative evaluation or carefully rephrase the claims as demonstrating feasibility of the visualization approach rather than established improvement in developer understanding.
[§3] The extraction pipeline is described only at a high level: TypeChef is modified to serialize the AST to XML, and a plugin is implemented to include C code and feature flags. It is not explained how feature flags are identified and extracted, how the mapping from preprocessor expressions to named flags is derived, or how macros such as ENABLE_DESKTOP, IF_DESKTOP, and IF_NOT_DESKTOP are resolved into the presence conditions shown in the visualization. Without this explanation, the reader cannot assess whether the flag list shown in the FeatureExplorer is complete or whether flags with complex expression dependencies are handled correctly. A concrete description of the extraction steps and a sample of the produced graph would strengthen the paper.

minor comments (6)

[Abstract, Keywords] There are typos in the abstract and keywords, e.g., 'variablity' and 'prodect line' should be corrected to 'variability' and 'product line'.
[Figure 2] The caption of Figure 2 uses inconsistent capitalization in 'fEATURE_find_EXEC' and 'fEATURE_find_XdEV'; these should be normalized to the actual feature flag names, e.g., FEATURE_FIND_EXEC and FEATURE_FIND_XDEV.
[§5] The sentence 'Our tool improves the developers understanding of the resulting structur and behavior' contains grammar and spelling errors ('developers' should be 'developer's', 'structur' should be 'structure').
[§6] The scalability claim 'We can visualize systems with up to four million lines of code without any problems' is unsupported: no measurements of rendering time, interaction latency, or memory usage are given, and 'a conventional notebook' is not a precise specification. The authors should either provide concrete measurements or qualify this statement as an observed limit rather than a general capability.
[§1, §5] The demo and screencast are only given as URLs. Since these are central for verifying the described behavior, the authors should provide a stable artifact, e.g., a DOI link or an archived repository, so that the demo remains accessible.
[Figure 1] The text refers to regions I, II, III, and IV in Figure 1, but the figure itself appears to use labels within the screenshot; a legend or a more explicit labeling would make the relation between text and figure clearer.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found; the paper's claims are empirical and self-contained, with external tooling (TypeChef) performing the extraction.

full rationale

The paper does not contain a formal derivation, equation, or fitted parameter whose output reduces to its input by construction. Its central claim is that a visualization tool helps developers trace the effect of CPP feature flags; that claim is supported by a BusyBox demonstration and a screencast, not by a chain of definitions or citations. The self-citations to Getaviz in Section 4 describe the toolkit as the implementation starting point, but they are not used as evidence for the correctness or completeness of the variability extraction. The extraction itself relies on TypeChef, an external tool from other authors, so the assertion that Q2 'can already be answered completely' is an empirical assumption about TypeChef's coverage rather than a constructional identity. The absence of an independent ground-truth validation is a legitimate correctness and generalization risk, but it is not circularity. No step in the paper's argument reduces a stated result to an input, renames a known result, or imports a uniqueness claim from the authors' prior work.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No free parameters or invented entities are introduced. The central assumptions are about the correctness of TypeChef's AST, the meaningfulness of extracted feature flags, and the usability of the adapted visualization; each is taken from prior work or asserted without validation.

assumptions (3)

domain assumption TypeChef's variability-aware parsing correctly handles all relevant C preprocessor constructs and macro expansions.
Section 3 states the parser should include CPP directives, nested conditions, and alternatives, and chooses TypeChef as best match without empirical validation of extraction correctness.
domain assumption Feature flags mapped from macros such as ENABLE_DESKTOP, IF_DESKTOP, and IF_NOT_DESKTOP correspond to meaningful configuration options.
Section 5 assumes macros affected by CONFIG_DESKTOP are automatically accounted for, but no mapping procedure or correctness measure is provided.
domain assumption The Recursive Disk metaphor, designed for Java packages and classes, remains an effective representation when remapped to C translation units, functions, variables, and types.
Section 4 describes adapting RD to C; the paper provides no empirical evidence that users understand the resulting visualization.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Understanding Conditional Compilation Through Integrated Representation of Variability and Source Code." pith.science (2026). https://pith.science/paper/3ZU7DOQS

@misc{pith2026190808375,
  author       = {Pith},
  title        = {Pith review of: Understanding Conditional Compilation Through Integrated Representation of Variability and Source Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3ZU7DOQS}},
  note         = {Machine review of arXiv:1908.08375}
}

read the original abstract

The C preprocessor (CPP) is a standard tool for introducing variability into source programs and is often applied either implicitly or explicitly for implementing a Software Product Line (SPL). Despite its practical relevance, CPP has many drawbacks. Because of that it is very difficult to understand the variability implemented using CPP. To facilitate this task we provide an innovative analytics tool which bridges the gap between feature models as more abstract representations of variability and its concrete implementation with the means of CPP. It allows to interactively explore the entities of a source program with respect to the variability realized by conditional compilation. Thus, it simplifies tracing and understanding the effect of enabling or disabling feature flags.

Figures

Figures reproduced from arXiv: 1908.08375 by the authors.

**Figure 2.** Visualizing the structure of BusyBox’s “nd.c” with three dierent congurations [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 22 canonical work pages

[1]

Badros and David Notkin

Greg J. Badros and David Notkin. 2000. A framework for preprocessor-aware C source code analyses. So/f_tware: Practice and Experience30, 8 (2000), 907–924

work page 2000
[2]

David Baum, Jens Dietrich, Craig Anslow, and Richard M¨uller. 2018. Visualising Design Erosion : How Big Balls of Mud are Made. In IEEE VISSOFT 2018

work page 2018
[3]

David Baum, Jan Schilbach, Pascal Kovacs, Ulrich Eisenecker, and Richard M¨uller

work page
[4]

Baxter and Michael Mehlich

Ira D. Baxter and Michael Mehlich. 2001. Preprocessor conditional removal by simple partial evaluation. In Proceedings Eighth Working Conference on Reverse Engineering. 281–290

work page 2001
[5]

Benjamin Behringer, Jochen Palz, and /T_horsten Berger. 2017. PEoPL: projectional editing of product lines. In 2017 IEEE/ACM 39th International Conference on So/f_tware Engineering (ICSE). 563–574

work page 2017
[6]

Janet Feigenspan, Christian K ¨astner, Mathias Frisch, Raimund Dachselt, and Sven Apel. 2010. Visual support for understanding product lines. In 2010 IEEE 18th International Conference on Program Comprehension. 34–35

work page 2010
[7]

Alejandra Garrido and Ralph Johnson. 2005. Analyzing multiple con/f_igurations of a C program. In 21st IEEE International Conference on So/f_tware Maintenance (ICSM’05). 379–388

work page 2005
[8]

Paul Gazzillo and Robert Grimm. 2012. SuperC: Parsing All of C by Taming the Preprocessor. Proceedings of the 33rd ACM SIGPLAN conference on Programming Language Design and Implementation - PLDI ’12(2012), 323. h/t_tps://doi.org/10. 1145/2254064.2254103

arXiv 2012

Show all 28 references

[9]

Lopez-Herrejon, and Alexander Egyed

Sheny Illescas, Roberto E. Lopez-Herrejon, and Alexander Egyed. 2016. Towards visualization of feature interactions in so/f_tware product lines. In 2016 IEEE Working Conference on So/f_tware Visualization (VISSOFT). 46–50

2016
[10]

Giarrusso, Tillmann Rendel, Sebastian Erdweg, Klaus Ostermann, and /T_horsten Berger

Christian K¨astner, Paolo G. Giarrusso, Tillmann Rendel, Sebastian Erdweg, Klaus Ostermann, and /T_horsten Berger. 2011. Variability-aware parsing in the presence of lexical macros and conditional compilation. ACM SIGPLAN Notices 46, 10 (2011), 805. h/t_tps://doi.org/10.1145/2...

2011
[11]

Christian K¨astner, Klaus Ostermann, and Sebastian Erdweg. 2012. A variability- aware module system. ACM SIGPLAN Notices 47, 10 (2012), 773. h/t_tps://doi.org/ 10.1145/2398857.2384673

2012
[12]

Jacob Kr¨uger, Ivonne Schr¨oter, Andy Kenner, Christopher Kruczek, and /T_homas Leich. 2016. FeatureCoPP: compositional annotations. (2016), 74–84. h/t_tps: //doi.org/10.1145/3001867.3001876

2016
[13]

Bernt Kullbach and Volker Riediger. 2001. Folding: An approach to enable program understanding of preprocessed languages. InProceedings Eighth Working Conference on Reverse Engineering. 3–12

2001
[14]

Livadas and David T

Panos E. Livadas and David T. Small. 1994. Understanding code containing preprocessor constructs. In Proceedings 1994 IEEE 3rd Workshop on Program Comprehension-WPC’94. 89–97

1994
[15]

Vi/t_tek

M. Vi/t_tek. 2003. Refactoring browser with preprocessor. InSeventh European Conference onSo/f_tware Maintenance and Reengineering, 2003. Proceedings. 101–110. h/t_tps://doi.org/10.1109/CSMR.2003.1192417

2003 arXiv
[16]

Bissyand´e, Jacques Klein, and Yves Le Traon

Jabier Martinez, Tew/f_ik Ziadi, Raul Mazo, Tegawend´e F. Bissyand´e, Jacques Klein, and Yves Le Traon. 2014. Feature relations graphs: A visualisation paradigm for feature constraints in so/f_tware product lines. In2014 Second IEEE Working Conference on So/f_tware Visualizati...

2014
[17]

ANDFONSECA

Fl´avio Medeiros, /T_hiago Lima, Francisco Dalton, M´arcio Ribeiro, Rohit Gheyi, and B. ANDFONSECA. 2013. Colligens: A Tool to Support the Development of Preprocessor-Based So/f_tware Product Lines in C. InProc. ´aBrazilian Conf. ´aSo/f_tware: /T_heory and Practice (CBSo/f_t)

2013
[18]

Richard M¨uller, Dirk Mahler, Michael Hunger, Jens Nerche, and Markus Harrer
[19]

Richard M¨uller and Dirk Zeckzer. 2015. /T_he Recursive Disk Metaphor – A Glyph- based Approach for So/f_tware Visualization. InProceedings of the 6th International Conference on Information Visualization /T_heory and Applications (IVAPP ’15). SciTePress, Set´ubal, 171–176. h/...

2015 doi
[20]

Daren Nestor, Steﬀen /T_hiel, Goetz Bo/t_terweck, Ciar´an Cawley, and Patrick Healy
[21]

Yoann Padioleau. 2009. Parsing C/C++ Code without Pre-processing. InCompiler Construction, Oege de Moor and Michael I Schwartzbach (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 109–125

2009
[22]

Diomidis Spinellis. 2010. CScout: A refactoring browser for C.Science of Computer Programming 75, 4 (2010), 216–231

2010
[23]

/T_homas /T_h¨um, Christian K¨astner, Fabian Benduhn, Jens Meinicke, Gunter Saake, and /T_homas Leich. 2014. FeatureIDE: An extensible framework for feature- oriented so/f_tware development.Science of Computer Programming 79 (2014), 70–85. h/t_tps://doi.org/10.1016/j.scico.2012.06.002

2014 doi
[24]

Simon Urli, Alexandre Bergel, Mireille Blay-Fornarino, Philippe Collet, and S´ebastien Mosser. 2015. A visual support for decomposing complex feature models. In 2015 IEEE 3rd Working Conference on So/f_tware Visualization (VISSOFT). 76–85

2015
[25]

Waddington and Bin Yao

Daniel G. Waddington and Bin Yao. 2005. High-/f_idelity C/C++ code transforma- tion. Electronic Notes in /T_heoretical Computer Science141, 4 (2005), 35–56

2005
[2008]

InProceedings of the 4th ACM symposium on So/f_tware visualization

Applying visualisation techniques in so/f_tware product lines. InProceedings of the 4th ACM symposium on So/f_tware visualization. 175–184
[2017]

InIEEE VISSOFT 2017

GETAVIZ : Generating Structural, Behavioral, and Evolutionary Views of So/f_tware Systems for Empirical Evaluation. InIEEE VISSOFT 2017

2017
[2018]

In Proceedings - 6th IEEE Working Conference on So/f_tware Visualization, VISSOFT 2018

Towards an Open Source Stack to Create a Uni/f_ied Data Source for So/f_tware Analysis and Visualization. In Proceedings - 6th IEEE Working Conference on So/f_tware Visualization, VISSOFT 2018. 107–111. h/t_tps://doi.org/10.1109/VISSOFT. 2018.00019

2018

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

Badros and David Notkin

Greg J. Badros and David Notkin. 2000. A framework for preprocessor-aware C source code analyses. So/f_tware: Practice and Experience30, 8 (2000), 907–924

work page 2000

[2] [2]

David Baum, Jens Dietrich, Craig Anslow, and Richard M¨uller. 2018. Visualising Design Erosion : How Big Balls of Mud are Made. In IEEE VISSOFT 2018

work page 2018

[3] [3]

David Baum, Jan Schilbach, Pascal Kovacs, Ulrich Eisenecker, and Richard M¨uller

work page

[4] [4]

Baxter and Michael Mehlich

Ira D. Baxter and Michael Mehlich. 2001. Preprocessor conditional removal by simple partial evaluation. In Proceedings Eighth Working Conference on Reverse Engineering. 281–290

work page 2001

[5] [5]

Benjamin Behringer, Jochen Palz, and /T_horsten Berger. 2017. PEoPL: projectional editing of product lines. In 2017 IEEE/ACM 39th International Conference on So/f_tware Engineering (ICSE). 563–574

work page 2017

[6] [6]

Janet Feigenspan, Christian K ¨astner, Mathias Frisch, Raimund Dachselt, and Sven Apel. 2010. Visual support for understanding product lines. In 2010 IEEE 18th International Conference on Program Comprehension. 34–35

work page 2010

[7] [7]

Alejandra Garrido and Ralph Johnson. 2005. Analyzing multiple con/f_igurations of a C program. In 21st IEEE International Conference on So/f_tware Maintenance (ICSM’05). 379–388

work page 2005

[8] [8]

Paul Gazzillo and Robert Grimm. 2012. SuperC: Parsing All of C by Taming the Preprocessor. Proceedings of the 33rd ACM SIGPLAN conference on Programming Language Design and Implementation - PLDI ’12(2012), 323. h/t_tps://doi.org/10. 1145/2254064.2254103

arXiv 2012