Comments intersperced with text below...
> N. Coesel wrote:
>
> >At 19:38 10-08-05 +0200, you wrote:
> >
> >>N. Coesel wrote :
> >>
> >>>Just a thought that pops into my mind: Is "long long int" a valid type?
If
> >>>
> >>>you want a 64 bit number, the proper type is "long long". I would not
rely
> >>>on the "int" type since the size of it depends on the architecture.
> >>>
> >>>
> >>long long
> >>signed long long
> >>long long int
> >>signed long long int
> >>
> >>all design the same type (whose size is implementation-dependent).
> >>
> >
> >No, a long is always 32 bit and a long long is always 64 bit; both are
> >implementation independant.
> >
> >Anyway, I have used the long long type on MSP430 without any problems.
> >
> >Nico Coesel
> >
I think you (Nico) are slightly confused by abbreviated type names - a type
such as "long long" is merely an abbreviation for "signed long long int".
All integer types (except char's) are "int", even if you omit it from the
name. Thus a "short" is really a "short int". They are also always
"signed", unless you specify "unsigned" - thus an "int" is really a "signed
int". So the four names listed above are all identical to the C compiler,
and as explained below they are all implementation dependant. A good rule
for readability is to always include the "int" - but don't bother with the
"signed" (except for "signed char", of course).
> >
> Wrong. The lengths of these integers are largely implementation
> dependant. The only thing the specs say is these names should imply
> minimum lengths. I think the lengths are:
> short is at least 16 bits
> long is at least 32 bits
> long long is at least 64 bits
> int is something natural for machine (although most 64 bit machines
> make an int a 32 bit number).
>
There is also an ordering in the sizes:
sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)
Thus you could not (following the standard) have 8-bit int's and 16-bit
short's on an 8-bit micro, even though 8-bit is more natural.
I'm not sure that "long long" actually has to be at least 64-bit - it was
not part of the original standard, though it could be required by C99
standard.
> 64 bit Linux machines, for example, obey the C spec by using:
> short is 16 bits
> long is 64 bits
> long long is 64 bits
> int is 32 bits
>
Whereas, I believe, in W64 a "long" is 32-bit, as is an "int", for
compatibility with code that was moved over from 16-bit windows (when an
"int" was 16-bit, and a "long" was 32-bit).
> mspgcc uses:
> short is 16 bits
> long is 32 bits
> long long is 64 bits
> int is 16 bits
>
> If you want specific lengths for integers, the standards compliant
> method is to include <stdint.h> and use:
> int8_t or uint8_t
> int16_t or uint16_t
> int32_t or uint32_t
> int64_t or uint64_t
>
> These are machine independant. In addition, because the relative lengths
> of ints and pointers varies, casting between ints and pointers should
> use intptr_t for the integer. This is guaranteed to be an integer
> capable of holding the full value of a pointer.
>
Of course, no one would cast a pointer to an integer, would they?
mvh.,
David
> Regards,
> Steve
>
