Messages in this thread | | | Subject | Re: C99 types VS Linus types | From | Albert Cahalan <> | Date | 07 Jul 2003 08:01:45 -0400 |
| |
Matthias Andree writes: > On Sun, 06 Jul 2003, Albert Cahalan wrote:
>> 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...
>> 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.
>> 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: > > unsigned char foo = 42; > char bar[42]; > sprintf(bar, "%ju", (uintmax_t)foo); // see IEEE Std 1003.1-2001 > > If that's too ugly, write your own [u]intmax_t-to-char[] > converter, then only the stack is nasty if uintmax_t is 128 > bits wide and you're printing an array uint8_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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |