> 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?
> 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.
> 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
-- Matthias Andree - 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/