Cedric,

>> > 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.

> Regards Hartmut

I think we lost the correct definition of bitwith along the way.

quoting earlier post from this thread:

> >>> recognized, that the bitwith (size of a type in bits) is

for me, bitwith( X ) == 8*sizeof( X )

If bitwidth is 8*sizeof(X), then you're right and I apologize for the

confusion.

If we speak of the same things, this was done in order to

thread the size of bitfield member in an uniform manner with

other 'normal'

variable.

Hmmm. Obviously I'm lost here or I'm mixing something up. (Please disregard

my statement you quoted above if it increases the confusion)

The point is, that if I'm looking at

clang/Basic/TargetInfo.h:+140:

/// getLongInfo - Return the size of 'signed long' and 'unsigned long' for

/// this target, in bits.

void getLongInfo(uint64_t &Size, unsigned &Align, SourceLocation Loc) {

Size = Align = 32; // FIXME: implement correctly: wrong for

ppc64/x86-64

}

/// getLongLongInfo - Return the size of 'signed long long' and

/// 'unsigned long long' for this target, in bits.

void getLongLongInfo(uint64_t &Size, unsigned &Align,

SourceLocation Loc) {

Size = Align = 64; // FIXME: implement correctly.

}

we use uint64_t for storing numbers which will have the max value of '64',

no?

Does this mean we need 64 bits to represent the _size_ of the variable or

does this mean we need 64 bits to represent the variable itself?

And sorry again for the noise.

Regards Hartmut