SoylentNews is people
SoylentNews
https://www.cossacklabs.com/blog/macros-in-crypto-c-code.html
Like death and taxes, one thing that you can be sure of is that using C macros in a modern software project will cause a debate. While for some macros remain a convenient and efficient way of achieving particular programming goals, for others they are opaque, introduce the unnecessary risk of coding errors, and reduce readability.
The criticism of macros is particularly acute in the wider security community. Among Cossack Labs' engineers and the core Themis crypto library contributors there are people who previously worked on auditing cryptographic implementations of critical code. Their typical knee-jerk reaction to macros was always "kill it with fire and never use it again". Taking no sides, we would like to assess both pros and cons of using such dangerous things as macros in security code (as we faced the issue when developing Themis) and suggest some techniques for lowering the accompanying risks.
We'll also discuss a custom "for-audit" build target for Themis designed specifically to generate source code that exposes the macros to inspection because we appreciate the need for security software to be subject to detailed source code scrutiny.
(Score: 2) by coolgopher on Sunday December 03 2017, @12:25AM
For all its bluntness, I miss the C-preprocessor whenever I'm in a language that doesn't support pre-processing (and doesn't lend itself to pre-processing via `make`). Commonly I also miss the relative type safety of C then.
A point maybe worth mentioning is that it's typically possible to use whatever pre-processor you want, it doesn't have to be /usr/bin/cpp. The stuff done in TFA could be implemented in that manner for example.
Gcc doesn't make it overly easy, though this post [stackoverflow.com] lists a way. I remember one compiler I used many moons ago had a simple -cpp switch with which you specify the pre-processor you wanted. It *might* have been the SunOS C compiler, but don't quote me on that please :)