C Is Not Assembly | Hacker News Reader

C Is Not Assembly

james-iry.blogspot.com

31 pointsblasdel14 comments

Their solution is not undefined. After casting to uintptr_t, the value is an unsigned integer which has well-defined overflow behavior. The casting itself is okay too because uintptr_t is guaranteed to be able to hold a pointer.

Their solution is well-defined but depends on undefined behavior. My understanding is that the casting is simply to prevent the compiler from optimizing out the check.

if((uintptr_t)buf+len < (uintptr_t)buf)

might fail to give the expected result if the address space is segmented.

The problem is that `buf+len` is still a `char*`. So it could still trigger undefined behaviour before it is converted to `uintPtr_t`. The real solution is to have `buf` declared as a `unitPtr_t` in the first place. Ugly, but standard.

No, (uintptr_t)buf + len is parenthesized like this: ((uintptr_t)buf) + len.

Whoops, my mistake. Forget what I said.

In short: don't add an integer to a pointer and expect reliable results.

Seriously? In 2010? We're still adding pointers to integers instead of working with actual data structures?

Every time you index an array in C you're adding an integer to a pointer.

Thank you. Adding ints to pointers--it's not just a good idea, it's the law! Because, in the end, it's all adding offsets to pointers.

No, we're not. If you read the linked advisory, you'll see it's only hypothetical. They don't cite a single example in the wild.

gcc did something unexpected. Film at 11.

They don't cite a single example in the wild.

I am aware of cases where gcc optimizing out this check resulted in security vulnerabilities. (No, I'm not going to give details. I think these were made public, but I'm not absolutely sure.)

I seem to recall seeing that as well, and I certainly don't have access to non-public data, but I can't find an example.

Of course, there is http://xorl.wordpress.com/2009/07/17/linux-kernel-devnettun-... (discussion at http://lwn.net/Articles/341773/), but while that is also an instance of gcc doing non-obvious but correct things, it's not the same problem.

So your question is basically "Why are we still using C in 2010?".

C is just a mapping to a generic assembly language. The machine will be adding pointers and integers anyway so this is inevitably reflected in C in one way or another. There are different notations to adding pointers and integers, such as &pointer[index] or casting and adding, but in C you still have to think in terms of pointers and integers.

Why C? The main reason is that it has lots of pragmatic bias for its use. It's simple (unlike C++), it's closeness to assembly makes it a nice candidate for writing low-level layers, and it's supported nearly everywhere (unlike C++). This is hugely important in getting things done even if there were a number of smarter but less pragmatic ways.

C++ can also be simple, if you define beforehand which constructs you will use from the language, and which not. For example, working with std::vector or std:string is usually much simpler than working with char* buff and pointer arithmetic.

But then you're essentially using C+std::string rather than C++. The reason it's simple is that you're ignoring most of the things that distinguish it from C — and even then it's actually quite a bit more complex in ways that you can't get around (e.g. extern "C").

Reply on news.ycombinator.com