Ack!
By sending this note to the 100-or-so folks on mpi-core,
you have probably increased by an order of magnitude the number
of people in the world who are aware of this fact about C. :-)
This is an MPI-1 issue - has anyone ever brought up the
issue before?
I make the alternate proposal: if we make any clarification,
we should clarify that MPI_BYTE refers to 8 bits as do other
references to "byte" (possibly with a clarification that there
may be unusual computers where strange things happen)
The reasons are:
1. ANSI C has this weird definition, but the (nearly) universally
understood meaning of "byte" is "8 bits" (unless qualified, as in
"4-bit bytes"). MPI is universal :-)
2. MPI also addresses Fortran and other languages. We now
have an MPI_SIZEOF function in Fortran that is not tied to C.
[An interesting experiment: do you have a Fortran compiler on
your machine, and does it support REAL*N, etc. If so, is REAL*N
of size N*32 bits or N*8 bits?]
3. Both the MPI-1 MPI_BYTE and the new Fortran datatypes
require that the size of a "byte" be the same on all machines.
MPI_BYTE is for transferring "raw" (untyped) data. If bytes are
different sizes, transferring raw data is impossible.
4. Throughout the MPI document and the "complete reference"
there are potential problem areas which we would need to
think about carefully. Fixing all this at this late date
is a practical impossibility.
---------------------------
That having been said, I agree that for your type of machine
there are problems. Many things in MPI-1 are defined in terms
of bytes or byte displacements or byte addresses.
Bill