Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday December 02 2017, @01:48PM   Printer-friendly
from the see-what-we-did-there? dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Pino P on Saturday December 02 2017, @11:49PM

    by Pino P (4721) on Saturday December 02 2017, @11:49PM (#604465) Journal

    debug macros wrappering logging

    This sounds similar to aspect-oriented programming.

    crossplatform/multiplatform system code substitutions

    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."

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2