
A Collection of Examples of 64-bit Errors in Real Programs - toni
http://software.intel.com/en-us/articles/collection-of-examples-of-64-bit-errors-in-real-programs/
======
asymptotic
I found myself chuckling at all the odd little pictures used to denote invalid
memory areas or edge conditions (16-bit Windows is a semi-truck stuck in mud,
integer truncation is the top of a truck getting shorn off by an overpass).
Haha!

This is definitely one of the more colourful technical documents I've read.

------
jrockway
_Despite the passing years, programs or some of their parts written in C
remain as large as life. The code of these programs is much more subject to
64-bit errors because of less strict rules of type checking in the C
language._

Yeah, because a language with 4 different typecast operators is type safe.

~~~
drv
As far as I know, C only has one; perhaps you are thinking of C++?

~~~
jrockway
I'm making fun of C++ programmers that think C++ is better than C, like the
authors of this article.

------
AndresNavarro
While some of these are great examples of common pitfalls with 64 bits errors,
I find it amusing that the first example has a deeper conceptual problem: You
can't (shouldn't) use memset to assign NULL to a pointer variable. In many
(maybe most) implementations the address 0 is used by the implementation for
NULL pointers but the standard allow any number (that can't be a valid
address). The compiler automatically converts both 0 and NULL to the proper
number when assigned to a pointer; but setting all bytes to 0 (as with memset)
only works in the implementations that actually use address 0 for NULL
pointers.

~~~
alok-g
I was under the impression that NULL is required to be zero by the standard by
now. If still not, it's high time that they give up! Differences like this
between theory and practice do not go away easily. The decision is changing
which one is easier, the culture or the rule...

~~~
caf
It hasn't, and it won't, because a definition of NULL as "all-bits-zero" would
be inconvenient for some embedded systems, where I/O ports or interrupt
vectors are mapped at low addresses.

------
Andys
Pretty basic stuff, but unfortunately when these errors are made in real life,
they are sometimes very hard-to-catch heisenbugs.

~~~
dhimes
I hadn't heard the term _heisenbug_! Here's a link for anybody else who may
not know the term (and others of that sort):
<http://en.wikipedia.org/wiki/Unusual_software_bug>

~~~
_delirium
Wikipedia's attempts to come up with names for these classes of things that
"everyone" already groups together, but which have no widely used name,
because it has to give the article _some_ sort of title, are a pretty nice
feature of the encyclopedia. "Unusual software bug" has a nicely euphemistic
feel to it too, sort of like "anomalous condition".

------
iqster
Ah ... I remember the good old days when you just had to be careful about big-
endian/little-endian when doing bit twiddling :)

------
malkia
The article failed to mentioned that there are few "C" language 64-bit models
- where ints, shorts and longs can be of different size (or all equal to the
pointer size). Some compilers, operating systems, and combinations of take one
model as preferred over another (or just assumes that model).

[http://en.wikipedia.org/wiki/64-bit#Specific_C-
language_data...](http://en.wikipedia.org/wiki/64-bit#Specific_C-
language_data_models)

~~~
derleth
Why do some people put C in quotes when talking about the language? Do they
also type "Java" or "Perl"? It's bizarre.

------
bartl
Non C/C++ user here...

A lot of the problems are due to the assumption an integer is big enough to
store a pointer.

Just wondering: is there a way to make the compiler barf if such an assignment
is done? Or for generating a runtime error if the assignment doesn't fit?

~~~
_delirium
I believe gcc will warn about this, unless you explicitly pass _-Wno-pointer-
to-int-cast_ , which will "suppress warnings from casts from a pointer to an
integer type of a different size."

------
veyron
This article can be summarized as follows: use size_t and ssize_t when doing
pointer arithmetic

~~~
mzl
Sure, as long as you are working with a standard and linear memory model. The
assumption that size_t and ptrdiff_t can store a pointer may break down on
segmented memory architectures for example. If you want to code against the
standard instead of an assumption, use uintptr_t and intptr_t instead.

~~~
cpeterso
When would someone want to use intptr_t instead of uintptr_t? Does a signed
memory address even make sense? Perhaps intptr_t is available to avoid
compiler warnings about mixing signed/unsigned ints when adding a uintptr_t
and a (signed) ptrdiff_t.

~~~
mzl
While I don't know of any specific use-case, it is of course very easy to
imagine an architecture with signed memory-address space. One could for
example separate protected/kernel memory from user land memory with the
signedness.

------
raphar
I get a:

504 Gateway Time-out nginx

Is this one of the example 64-bit errors?

Edit: Now it's working

