This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] HOST_WIDE_INT transition steps


"Joseph S. Myers" <joseph@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]