On Tue, 20 May 2014, Eric Botcazou wrote: > > Make the code base easier to understand for newcomers. It's also a > > documentation improvement (you see what a HOST_WIDE_INT really is), > > alongside with [u]int64_t being less to type ... > > I personally find the abstraction and the separation with the other, more > mundane types useful, but I guess that it's a matter of habit.
Whatever the abstraction is, HOST_WIDE_INT is a pretty poor name for it. I think it's something like "integer type that is big enough to store a target address / offset in bytes, or a target word", together with a sense of "integer type big enough for certain constants and such that twice it is big enough for other constants" (the latter being what wide-int should enable eliminating eventually). But I suspect HOST_WIDE_INT is used for lots of other things as well - and for things for which 64 bits may not be enough (bit offsets, for example), and for that matter int is used for things for which HOST_WIDE_INT would be more appropriate (the length of a STRING_CST, for example). So while there may be a meaningful abstraction somewhere in there, I don't think the particular places that happen to use HOST_WIDE_INT are a very good guide to where such an abstraction should be used - and don't think moving to int64_t / uint64_t would actually lose information of use for cleaning things up in future. (HOST_WIDEST_INT should of course become intmax_t. It should also not be used in any way that can affect code generation.) -- Joseph S. Myers jos...@codesourcery.com
