On Nov 29, 2012, at 4:23 PM, Stephen Canon <[email protected]> wrote:
> On Nov 29, 2012, at 7:16 PM, Richard Smith <[email protected]> wrote: > >> Generally, we still need to handle Eli's observation that the C and C++ >> extended integer type rules require us to make intmax_t be __int128 if we're >> going to allow literals to be of type __int128. I'm inclined to say we >> should bite the bullet here, and treat __int128 as a proper extended integer >> type (and thus change intmax_t, preprocessor constant expressions, and so >> on). Any objections? > > In the long run, I would very much like for intmax_t to be 128-bits where we > can do so, but it's a *major* undertaking. In particular, it requires > considerable platform library support; off the top of my head: > > • libc needs to be able to printf/scanf intmax_t via SCN*MAX / PRI*MAX, and > needs to support strtoimax, etc. > • libc needs to support imaxdiv and imaxabs. > > This will cause a decent amount of binary-compatibility headaches. It's a > goal worth aiming for, but it's a good ways off still. I agree, it's a great goal, but it will be a massive undertaking. -Chris _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
