5 ms·
You might as well just use a 64 bit int if you're going to be changing code anyways But this blog post is about how code which is already using 64 bit ints can
by __s 5y ago
You might as well just use a 64 bit int if you're going to be changing code anyways
But this blog post is about how code which is already using 64 bit ints can have code which silently truncates. Another case of C's loose handling of types, whereas in Rust there would've been an explicit cast required (granted, in this case the macro expands to having explicit type casts)
- froglips 5y ago
- __s 5y agoI'll have you know many "rust guys" like myself are willing to program with whatever we have to. My career has involved quite a bit of C, & I'll agree its simplicity is alluring. But damn if people don't come up with more & more creative ways to cause segfaults
- koolba 5y ago> You might as well just use a 64 bit int if you're going to be changing code anyways That’s such a waste though. We could the current Unix time as is, and use a single additional bit to indicate if it’s the original epoch, or the new one. Imagine the net savings worldwide by using only 33 bits rather than 64 for the next 68 years.
- lostcolony 5y agoWhat net savings? Dates will still get padded out to a byte alignment when in memory and being processed on the CPU (or gods help us all). You'd just be making it so there's extra handling any time you serialized it across I/O, to save a few bytes there. If you really wanted to save those bytes you can write your own serialization format, and that might make sense if you're sending massive amounts of timestamps or similar (but you'd probably see better results by compressing it first), but don't try and rope the rest of us into that pain when we aren't, like, serializing logs or something.