4 ms·
Figure 1 spoke to me. It's an expanded syntax tree that branches depending on on the value of a preprocessor definition "CONFIG...X". I've often found myself do
by DriftRegion 3y ago
Figure 1 spoke to me. It's an expanded syntax tree that branches depending on on the value of a preprocessor definition "CONFIG...X". I've often found myself doing the kind of code archeology that this paper seems to be trying to automate: exploring all the configuration possibilities implied by the codebase / build system. A C program that makes heavy use of the preprocessor is generally harder to grok by both h humans and static analysis because 1. the C preprocessor syntax is different from C, 2. the inputs are not necessarily bounded by what appears in the source files alone ("-DCONFIG...X=foo" passed in from the build system), and 3. the resulting program and its control flow may be quite different depending on preprocessor options. As a simple example embedded systems often define an "ASSERT(X)" macro as either noop, an infinite loop, a print statement or the like.
This is definitely a niche space but I see clear use for large, portable and configurable c codebases (e.g. Linux kernel, FreeRTOS) for providing better visibility into the configuration system.
- senkora 3y agoYou may be interested in unifdef, which selectively evaluates and removes ifdefs. https://dotat.at/prog/unifdef/ https://dotat.at/prog/unifdef/ I used it once at work for a niche usecase. It’s main use case seems to be making it easier to simplify platform-specific code when you remove support from old platforms in legacy codebases.
- peter_d_sherman 3y agoIt seems that the use of macros/IFDEF (in any language, not just C) -- bifurcates into two distinct use-cases: 1) Platform/Processor/OS configuration/build use-cases. (and) 2) All other use-cases that are not directly related to #1. In other words, if you're a future language designer and you design a macro system for your language, you might wish to distinguish between configuration/platform/build related macros -- and other macros not directly related to build and configuration... Doing that would allow one set and/or the other set to be selectively and easily evaluated back into the non-macro source of the base language -- depending on what is desired by the language user... Anyway, an excellent link!