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, Insightful) by The Mighty Buzzard on Saturday December 02 2017, @02:16PM (9 children)
Anyone using macros in production code should be killed to death unless they expand the macro in a comment above each use. It may save your monkey ass a few keystrokes but it costs every single person who ever has to touch your code at least an order of magnitude more time than it saved you.
My rights don't end where your fear begins.
(Score: 3, Insightful) by c0lo on Saturday December 02 2017, @02:35PM (5 children)
You mean `(g)cc -E` ? Yeah, that's a hard one.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by The Mighty Buzzard on Saturday December 02 2017, @02:53PM (4 children)
Which means you have to have two copies of every file you're working on open and remember not to type in the one you can read? Yeah, that's a real winner of an option.
No, man, there is no good argument for decreasing readability of production code to save one person some time. Not with 1337 perl that only you can read and not with C macros.
My rights don't end where your fear begins.
(Score: 5, Insightful) by tonyPick on Saturday December 02 2017, @03:37PM (3 children)
Counter-examples: debug macros wrappering logging, handling vestigial compiler warnings while using -Wall/-Werror, crossplatform/multiplatform system code substitutions....
I'd argue overly verbose commenting, like "expand the macro in a comment" does more to reduce readability, and clean/hygenic/referentially transparent macro implementations can improve it.
(On the other hand there's a special circle of hell reserved for people who write macro code that doesn't behave like that, and a lower one for people who make macros that don't *very* *obviously* look like Macros at first glance.)
(Score: 2) by Pino P on Saturday December 02 2017, @11:49PM
This sounds similar to aspect-oriented programming.
Let me predict the anti-macro hardliners' likely response, based on what I've picked up in discussions on this site and others like this about web applications:
Anything that can vary from one platform to another ought to be in a separate file or separate set of files, one for each platform. That way, instead of #ifdef MACOS, you get macos.c. You end up with a driver for each platform that implements a common interface to the platform-independent parts of the program. For things like common data types used by the platform-independent parts, you can use typedef instead of macros.
Or better yet, if there's a business case to make your client application available to users of multiple platforms, there's probably a business case to give the same client spec to separate programming teams, each specializing in a different client platform, so that each platform can get a client application that ideally plays to the strengths and user expectations of each platform. For example, the Mac and iOS versions can take advantage of Core Data."
(Score: 2) by coolgopher on Sunday December 03 2017, @12:28AM
Amen.
Add to that another really common one, being rounds of cryptographic operations.
Macros *increase* readability when used properly.
(Score: 2) by The Mighty Buzzard on Sunday December 03 2017, @02:24AM
You're entitled to your opinion. I just hope I never have to come behind and fix any of your code.
Yeah, that would only be a problem if you can't read the code well. If you understand what you're looking at, seeing the actual code adds clarity instead of removes it. If you don't, you need to step back from the keyboard and hand the project off to someone who does.
My rights don't end where your fear begins.
(Score: 4, Touché) by bzipitidoo on Saturday December 02 2017, @05:27PM (2 children)
What's your feeling about code generators? Code to generate code? How about templates? Do you hate them too, or only the way C macros goes about it?
(Score: 2) by Pino P on Saturday December 02 2017, @11:53PM
It depends on the difficulty of either formally proving the correctness of the code generators or auditing their output. The featured article is about making a code generator's output more auditable.
The key difference is that C++ templates are more type-safe than C preprocessor macros. But C preprocessor macros still have two advantages: availability on platforms with no C++ compiler (such as MOS 6502), and ability to use __FILE__ and __LINE__ at the place where a macro is used as opposed to where it is defined.
(Score: 2) by The Mighty Buzzard on Sunday December 03 2017, @02:12AM
I have no love for any "I'm too lazy to type this out every time and too 1337 to just abstract it out with a wrapper function" code. Not in any language.
My rights don't end where your fear begins.