Did you know Node.js uses IEEE double (53-bit) to store an inode number (64-bit)? Well now you do. And if you ever wondered why I think Node.js is unsuitable for even basic usage and must be avoided for anything you intend to run in any capacity n>=0 times, here's another reason.
https://github.com/nodejs/node/issues/12115#issuecomment-290064494
@voidstar And I'm guessing this is because they're putting it in a JS numeric field somewhere, right? There's hundreds of other things I like about node.js, and inode numbers aren't really a thing I've ever needed to use so far... So I'm gonna disagree with you there.
@thor Quite likely it is, but with Node being increasingly used for regular apps (see Atom, with a wide install base, where this could be highly relevant) I think this is actually something they should fix. And since they expose it, it's not something bolted on, they should have dealt with it when they first created that ability.
@voidstar How would they implement it properly, exactly? There's no 64-bit integer type in JS. If node stored this number in 64-bit form, they'd be forced to cast it to double almost immediately, because all the rest of their code is probably designed around that. It actually seems like a genuinely tricky problem to solve. Maybe they could use a two-element UInt32Array...
@thor Node.js has the capability of using native code, they could write portable C to handle it internally. As an exposed interface, yea probably UInt32[2] but ideally everything needing >53-bit integers (or numbers) could use native code. Like some kind of native generic "bignum" library this uses. 64-bit integers in native code have been around longer than UInt32.
@thor And if you want to allow Node without native code, make it optional and have the functions spew warnings about possible integer truncation if they aren't backed by native code.