
C Is Not Assembly - blasdel
http://james-iry.blogspot.com/2010/04/c-is-not-assembly.html
======
ssp
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.

~~~
loup-vaillant
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.

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

~~~
loup-vaillant
Whoops, my mistake. Forget what I said.

------
lsb
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?

~~~
yason
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.

~~~
greyman
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.

~~~
chc
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").

