[sv-cc] Item 205: 64-bit concerns

On closer inspection, I do not believe that the prevalence of "64-bit
machines"
would pose any unique difficulties for binary-compatible packed types
based on
32-bit chunks.

Here are three reasons.

a. Even pervasive use of '64-bit machines' is very unlikely to make C
compiler vendors
   change the size of 'unsigned int' to 64-bits. They might make 'long'
and 'long long' consume
   64-bits on more platforms. However, changing the size of 'int' to 64
bits would render
   many thousands of C programs obsolete. This is unlikely.

b. Most important is that Item 205 intends to tie the vendor chunk size
to the canonical chunk size
    (which happens to be 32 bits). The match between unsigned ints and
32-bits already exists in the LRM.
    . Each canonical chunk is defined in terms of unsigned int (E.9.1.2,
F.1) and the LRM
      expects it to be "representing 32 bits" (E.6.7).
    . Similarly, we also have 2-state values <= 32 bits passed by value
in unsigned ints (E.7.7).

    Thus, the LRM expects C unsigned ints to be 32-bit entities. This
is not specific to Item-205.
    
c. Various suggestions are already in the works to tie the size of our
canonical forms and
    proposed forms to definitions such as uint32_t or something like it.
Given the extreme
    unlikelihood of all 32-bit C integer types disappearing, this should
provide a sound basis for
    specifying the size of embedded packed types.

Summary: The disappearance of a 32-bit C integer types is extremely
unlikely. Regardless of 205's fate we
already have 32-bit values tied to unsigned ints. We are also already
at work (separately) on a robust way
of indicating C data type sizes.

Ralph Duncan
Mentor Graphics
Received on Wed Nov 3 08:01:41 2004