Sign In

Communications of the ACM

Practice

C Is Not a Low-Level Language


C Is Not a Low-Level Language, illustration

Credit: Bug Fish

back to top 

In the wake of the recent Meltdown and Spectre vulnerabilities, it is worth spending some time looking at root causes. Both of these vulnerabilities involved processors speculatively executing instructions past some kind of access check and allowing the attacker to observe the results via a side channel. The features that led to these vulnerabilities, along with several others, were added to let C programmers continue to believe they were programming in a low-level language, when this hasn't been the case for decades.

Processor vendors are not alone in this. Those of us working on C/C++ compilers have also participated.


Comments


Martin Sandberg

This article makes a common fundamental mistake - that language are really powerful. They are not. Let me use that analogy of modern machine tools to illustrate my point.

Assembler - a basic hand tool, a file, a chisel, a screwdriver
C - perhaps a drill press
C++ - A table saw with some attachments, such as a mortising jig

We're done. We haven't even reached the level of a multi-axis CNC machine.

Since languages aren't powerful, coders have to do the heavy lifting. Therefor, good and bad code can be written in ANY language. Most GPUs are coded in C with some special operators or library calls, after all. I've written C programs that spawn off threads by the thousands as required by the work load.

In C++ it is even easier. For example it's possible to make thread-safe blocks completely trivial. Here's a complete header file:

// ===========================================================================
//
// A simple way to get locking and unlocking a pthread mutex correct. Just
// put:
// threadLock lockThis(pointer to your pthread mutex)
// at the beginning of the exclusive section of the code and when it goes out
// of scope at the end of the section, the mutex will be unlocked by the
// destructor.
//
// ===========================================================================
// Modification History:
//
// 06/13/2011 - File Created (MCS & WLH)
//
// ***************************************<< o >>***************************************

#include

class threadLock{
public:
threadLock(pthread_mutex_t *theLock):myLock(theLock){pthread_mutex_lock(myLock);};
threadLock(pthread_mutex_t &theLock):myLock(&theLock){pthread_mutex_lock(myLock);};
threadLock(const threadLock& source):myLock(source.myLock){};
threadLock& operator =(const threadLock &rhs){
if(this == &rhs)
return *this;
myLock = rhs.myLock;
return *this;
};

~threadLock(){pthread_mutex_unlock(myLock);};

pthread_mutex_t *myLock;
};


Displaying 1 comment

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.
  

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.