"Joseph S. Myers" <jos...@codesourcery.com> writes: > 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.
Same here FWIW. And int64_t and uint64_t have the advantage of being "proper" types rather than #defines, which has caused surprises in the past. (E.g. a case where HOST_WIDE_INT (x) worked for most hosts but not mingw64.) We wouldn't be able to get away from using the #define without also replacing "unsigned HOST_WIDE_INT" with something else, which wouldn't be much less invasive than replacing all HOST_WIDE_INTs. And I can't help thinking that people have used HOST_WIDE_INT not because they needed a signed type with undefined overflow, but because it was less to type. Richard
