C99 types VS Linus types
Quoted 7 lines · Matthias Andree
Quoted 3 lines · Albert Cahalan
Sure, both are "correct", but there would be a lot less pain and suffering in the world if "unsigned long long" would be used for 64-bit.
What if unsigned long long is 96 bit? or 128?
I think you're trolling, but just in case not...
The days of non-power-of-two word sizes are gone for normal computing. Sign-magnitude and ones-compliment are dead too. Float is IEEE format, possibly skipping a few costly features. Nobody is going to go back to the old way.
It's too bad the C99 committee didn't have the guts to make this official.
As for 128-bit...
Quoted 6 lines
Quoted 2 lines
It ought to be at least 40 years
before 128-bit types begin to matter.Yup, and 8-Bit CPU and 640 kB RAM ought to be enough for...
nevermind.
There's a logrithmic/exponential thing going on. Measuring bits isn't like measuring kB. It's log(kB), which interacts with Moore's law to give a plain linear need for bits. It took about 20 years to eat through the extra bits we got with 32-bit CPUs. Now we have twice as many bits to eat through. So that's 40 years right there. People will make do for much longer though; notice that 8-bit was never comfy while 32-bit was.
Quoted 8 lines
Quoted 5 lines
In the Linux world,
we can consider "long long" to be 64-bit, "int" to be 32-bit, and "long" to be the same size as a pointer. Then we can ditch the nasty casts:sprintf(foo, "%llu", (unsigned long long)bar);Speaking of shifting forward to standards:
Quoted 7 lines
unsigned char foo = 42;
char bar[42];sprintf(bar, "%ju", (uintmax_t)foo); // see IEEE Std 1003.1-2001If that's too ugly, write your own [u]intmax_t-to-char[] converter, then only the stack is nasty if
uintmax_tis 128 bits wide and you're printing an arrayuint8_t. :-P
Yes, that is too ugly. It's idealistic code. Readability matters more than worrying about something which won't happen for over 40 years, and won't cause Y2K-style problems even then.
If I live that long, I'll need employment anyway.
Perfection is the enemy of good. In practice, there is a difference between theory and practice. Etc.
Quoted 6 lines · Albert Cahalan
Quoted 6 lines
Speaking of shifting forward to standards:
unsigned char foo = 42;
char bar[42];sprintf(bar, "%ju", (uintmax_t)foo); // see IEEE Std 1003.1-2001
Quoted 8 lines
Quoted 3 lines
If that's too ugly, write your own [u]intmax_t-to-char[] converter, then only the stack is nasty if
uintmax_tis 128 bits wide and you're printing an arrayuint8_t. :-PYes, that is too ugly. It's idealistic code. Readability matters more than worrying about something which won't happen for over 40 years, and won't cause Y2K-style problems even then.
sprintf doesn't lend itself too well to readibility anyways, and we have these crutches in gcc to check argument types and all that, not to speak of %n and other time bombs.
Signature · 1 line
Matthias Andree
Quoted 8 lines · Albert Cahalan
The days of non-power-of-two word sizes are gone for normal computing. Sign-magnitude and ones-compliment are dead too. Float is IEEE format, possibly skipping a few costly features. Nobody is going to go back to the old way.
It's too bad the C99 committee didn't have the guts to make this official.
The C99 people have to handle non-normal computing too. C has lots of little quirks (like pointers off the end of array rules) from this.