Hacker News Reader

Comment by xigoi | Hacker News Reader

So previously it worked for arrays up to length 2³⁰ and now it works for arrays up to length 2³¹. Is it really that much of a difference? Wouldn’t it be better to change the indexing type to a 64-bit integer?

View on HN

The difference is that we know for a fact that the proper implementation works for integers up to 2^31, whereas the improper implementation deceived us into thinking that the code would work in situations where the code actually doesn't work.

I find it valuable to understand when my code will crash.

Article was written in 2006 when 32-bit architectures were dominant.

I suppose the issue is moot now on 64-bit architectures, as the difference between 2^62 and 2^63 isn't relevant. (2^62 bytes is 4611686 terrabytes.)

Spelling it out like that sure gives some perspective - It's a frighteningly low number! They sell 2tb microsd cards nowadays. I bet you could fit 2^64 bytes in a shoebox. So I think uint64 might eventually be insufficient as a size type.

Edit: Well not quite, more like a small closet.

Almost makes you think RISC-V was right with 128-bit extension. On the other hand, exabyte-scale memories might one day be possible, but would it still be useful to maintain single-address-space illusion for these?

RV128I is not an extension, but a (non-ratified) base ISA.

Independent from RV64I, which in turn is independent from (and predates) RV32I.

>Spelling it out like that sure gives some perspective - It's a frighteningly low number!

Yeah, it's very common for computers to have byte addressable 4 exabytes of storage...

Well I used to think 64 bits would be enough forever basically, I guess that's why I was a little shocked that it actually might become insufficient at some point even if its far off.

I do not look forward to the future where common software requires exabytes of memory.

I'd say it's more likely that in the future we'll regress to 8-bit machines, losing the ability to sustain fab technology, than we'll exhaust 64 bits address space.

Having said that, with the advances of Electron apps, you might very well have a point...

The use of:

   int high = a.length - 1;

tells us that a.length-1 is supposed to fit into an int, so there is no need to handle 2³¹ or larger.

Yep. No story here, feel free to move on...

Not really. Arrays are limited to an int in size. You would be using more memory for the calculation and have to cast the value down to a 32 bit value to use as an array index.

Or you could just write the code so it isn't vulnerable to integer overflow.

Ideally the index should support int64 with int being a synonym on a 64bit platform by default.

If not yes frankly you're into such unexpected behaviour territory that you should check your whole codebase rather than rely on stuff working just because it compiled.

And we all know how everyone loves writing and understanding integration tests... (I personally do but most problems in the industry wouldn't be a thing if more people stopped to write them)

size_t, you mean?

Well yes by inference

Java doesn’t have a type that corresponds to size_t. It only has signed integer types, so the closest match is ssizet_t (but even then you need to figure out how many bits that is on your architecture).

J8 has unsigned integer arithmetic at least.

Which is sad (array size limited to an int) and has always annoyed me, coming back from Ada where the index of an array is just another discrete type (including boolean, enum type, and ranged integers).

Reply on news.ycombinator.com