Hacker News Reader

Comment by dreamcompiler | Hacker News Reader

One of the things I love about Lisp is that i+1 is always greater than i. You can work hard to make that not be true, but that's the default and IMHO it's the proper default.

View on HN

Well, that's the case for signed integers in C as well.

(But only on a technicality: because every program where that breaks is not technically C, and the compiler is allowed to assume this doesn't happen.)

I suspect the Lisps you talk about use arbitrary sized integers by default? Python also has that default. It's a good default. If you want to optimize for size and want an integer of limited size, like a 64 bits or so, you should explicitly specify.

Yep, the [numerical tower][1].

Python's int is a bignum, but in Scheme you even have rationals built in. There's a notion of which numeric values are "exact" and which ones are "inexact" (i.e. floating point).

[1]: https://en.wikipedia.org/wiki/Numerical_tower

I remember the numerical tower from Scheme. That was an interesting concept. (Though mathematically, you might want something with a more complicated structure than a tower. Eg p-adic numbers would sit below integers, next to rational numbers, but not below them.)

Python has rational numbers in the standard library. They are easy to use there, too.

Every rational number is a p-adic number (though not necessarily a p-adic integer, of course). So doesn't that mean p-adic numbers would be below rationals?

Sure, maybe. My broader point is that the tower would branch at some point.

This is dangerous for security, because now your math operations are no longer O(1) and might allocate memory.

I think, if security is involved, one would still need to do overflow checks in the exact same places, so nothing is gained and nothing is lost.

Might allocate a _lot_ of memory. I've actually seen a case where some fatfingered a comparison in Python as a << b instead of a < b, and allocated gigabytes of memory on a server.

Side channels are hard to prevent in all languages because of compiler optimizations, out-of-order execution, branch prediction, speculative execution, loop unrolling, eliding operations, register renaming, using the FPU under the sheets for ordinary integers, clock throttling, cache usage, rowhammer, etc.

Modern mostly-hidden, mostly-proprietary architectural execution models are hell for security and side channel prevention.

We need chips from 1984 with Ghz clocks if we want good security.

Oh, this isn't (mainly) about sidechannel leaks. It's about DoS attacks.

If you want to harder your code against timing attacks, you need to actively work hard, instead of just relying on some operations taking O(1).

(I don't even know whether your processor does regular multiplication and division in O(1)?)

> (I don't even know whether your processor does regular multiplication and division in O(1)?)

Most of them don't, especially division.

Reply on news.ycombinator.com