4 ms·

The code was written 20 years ago, but the -bug- didn't appear until people started writing 64-bit software. I wouldn't call that a 20-year-old bug... It didn

The code was written 20 years ago, but the -bug- didn't appear until people started writing 64-bit software. I wouldn't call that a 20-year-old bug... It didn't cause any issues for most of that time because it couldn't have.

forgotusername 15y ago
I guess, practically that's true, but the original code still violated the constraints of the abstract machine for which it was written (it assumed pointer sizes valid only for particular implementations of C++, etc.)
lukesandberg 15y ago
using subtraction for comparison can easily be broken due to overflow. This particular case may have been fine... but i wouldn't count on it.
cperciva 15y ago
It was a bug. It should have had assert(sizeof(void *) <= sizeof(int32)); (or better yet, a compile-time assertion).
- alttab 15y ago
  Can you imagine that "20 years ago" (for most of us is too early to be programming at this level) you missed this thinking it couldn't possibly be anything but 32 bits for the purpose it was written for? That said, never assume, because "dict.cpp" stuff happens all the time, except its modern web-incantation is usually called "copy-pasta."
  - zwischenzug 15y ago
    Only if you'd been raised on Java. There had been the shift from 16->32 bit not long before that, so it's not that much of a stretch, and 8->16 before that (well after I got my first computer). We found an almost identical bit-mismatch bug in a programming language that led a bitmap of tcp connections to appear to go crazy on a customer install in a core piece of software. These bugs cost.
    - tsotha 15y ago
      Yeah, in that time period you couldn't really get away from writing really defensively. It was even worse, earlier. When I wrote C code for x86 there were all sorts of different memory models you could choose from at compilation, and we were producing both a 16 bit and a 32 bit (for the daring) versions of our product. You couldn't assume anything. I write java now and this is not something I miss.
  - Roboprog 15y ago
    I love cperciva's solution. OK, not solution, but at least paranoia. Back when I worked at a place called Morada in the early 90s, we had to port a C runtime library for the product to everything from 16 bit x86 "real mode" (DOS) to 64 bit DEC-Alpha, so word sizes were all over the map. Trying to define portable size definitions in C can make you crazy (e.g. - such as trying to save a tokenized binary file from source code, such that the binary ports between platforms). Kudos to the author for finding this bug.
mikeash 15y ago
64-bit architectures were around 20 years ago. It was pure luck (whether good or bad I'll leave up to the reader) that it didn't get exercised enough to show up until now. The code invoked undefined behavior which just happened to work on the architecture it was targeting at the time. That's still a bug, even if the result works as expected, precisely because it could stop working as expected later.
- Retric 15y ago
  20 years ago computers where a lot slower so some tradeoffs into "undefined behavior that happens to work quickly" was fairly common practice. Personally I prefer to call such things landmines vs bugs because they where often left there deliberately.
kragen 15y ago
There have been significant 36-bit and 60-bit machines since at least the 1960s and 64-bit machines since the 1970s. Notably, Digital's PDP-10 line that ran the early internet were 36-bit, and Crays (from 1977) were 64-bit. However, none of those machines had 64-bit addresses. I think the Alpha may have been the first mainstream machine with 64-bit addresses, and it didn't come out until 1992, only 19 years ago. (I don't remember if the i860 had 64-bit addresses or not, but it came out a few years earlier.)

forgotusername 15y ago

I guess, practically that's true, but the original code still violated the constraints of the abstract machine for which it was written (it assumed pointer sizes valid only for particular implementations of C++, etc.)

lukesandberg 15y ago

using subtraction for comparison can easily be broken due to overflow. This particular case may have been fine... but i wouldn't count on it.

cperciva 15y ago

It was a bug. It should have had assert(sizeof(void *) <= sizeof(int32)); (or better yet, a compile-time assertion).

alttab 15y ago
Can you imagine that "20 years ago" (for most of us is too early to be programming at this level) you missed this thinking it couldn't possibly be anything but 32 bits for the purpose it was written for? That said, never assume, because "dict.cpp" stuff happens all the time, except its modern web-incantation is usually called "copy-pasta."
- zwischenzug 15y ago
  Only if you'd been raised on Java. There had been the shift from 16->32 bit not long before that, so it's not that much of a stretch, and 8->16 before that (well after I got my first computer). We found an almost identical bit-mismatch bug in a programming language that led a bitmap of tcp connections to appear to go crazy on a customer install in a core piece of software. These bugs cost.
  - tsotha 15y ago
    Yeah, in that time period you couldn't really get away from writing really defensively. It was even worse, earlier. When I wrote C code for x86 there were all sorts of different memory models you could choose from at compilation, and we were producing both a 16 bit and a 32 bit (for the daring) versions of our product. You couldn't assume anything. I write java now and this is not something I miss.
- Roboprog 15y ago
  I love cperciva's solution. OK, not solution, but at least paranoia. Back when I worked at a place called Morada in the early 90s, we had to port a C runtime library for the product to everything from 16 bit x86 "real mode" (DOS) to 64 bit DEC-Alpha, so word sizes were all over the map. Trying to define portable size definitions in C can make you crazy (e.g. - such as trying to save a tokenized binary file from source code, such that the binary ports between platforms). Kudos to the author for finding this bug.

mikeash 15y ago

64-bit architectures were around 20 years ago. It was pure luck (whether good or bad I'll leave up to the reader) that it didn't get exercised enough to show up until now. The code invoked undefined behavior which just happened to work on the architecture it was targeting at the time. That's still a bug, even if the result works as expected, precisely because it could stop working as expected later.

Retric 15y ago
20 years ago computers where a lot slower so some tradeoffs into "undefined behavior that happens to work quickly" was fairly common practice. Personally I prefer to call such things landmines vs bugs because they where often left there deliberately.

kragen 15y ago

There have been significant 36-bit and 60-bit machines since at least the 1960s and 64-bit machines since the 1970s. Notably, Digital's PDP-10 line that ran the early internet were 36-bit, and Crays (from 1977) were 64-bit. However, none of those machines had 64-bit addresses. I think the Alpha may have been the first mainstream machine with 64-bit addresses, and it didn't come out until 1992, only 19 years ago. (I don't remember if the i860 had 64-bit addresses or not, but it came out a few years earlier.)