[cfe-dev] Inconsistent types used to represent bitwidth
hartmut.kaiser at gmail.com
Thu Oct 4 05:30:01 PDT 2007
> >>> I'm currently trying to remove some of the warnings spit
> >> out on me by
> >>> the
> >>> VC++ compiler (mostly warnings about possible loss of
> precision) and
> >>> recognized, that the bitwith (size of a type in bits) is
> >> represented
> >>> using different types all over the place: sometimes unsigned,
> >>> sometimes uint32_t and sometimes it's even uint64_t. I
> really would
> >>> like to change that to a more consistent scheme, but need
> >> some advice
> >>> which type to choose.
> >>> Since I
> >>> think we can't expect to get anything terribly large as the
> >> bitwidth
> >>> of a type I'ld say let's go for uint32_t.
> >> Hi Hartmut,
> >> We should go with uint64_t in general. There can be large arrays
> >> (for example) on 64-bit targets that need this. For "known little
> >> things" like integer types, uint32_t would be sufficient,
> but it is
> >> probably better to be consistent and use uint64_t for everything.
> > IIUC, the bitwidth is most of the time the number of bits needed to
> > represent the size, i.e. 32 for uint32_t. In this case 64 is the
> > largest number these kind of variables will ever hold, no?
> Yes, except that what is the size of "uint32_t[100000000000LL]" ?
sizeof(uint32_t[100000000000LL]) < 2^64,
so the size is representable with 64 bits, which means the corresponding
bitwidth is not even '64', which conveniently fits into a int8_t.
But probably I'm getting something really wrong here.
More information about the cfe-dev