Is an object made up of bytes?

msb at sq.UUCP msb at sq.UUCP
Fri Jan 16 12:52:25 AEST 1987


Richard Stallman says [in effect]:
>  I am not sure whether the standard implies that, given "short in, out;",
> 
> {   char *inptr, *outptr; int i;
>     inptr = (char *) ∈ outptr = (char *) &out;
>     for (i = 0; i < sizeof (short); i++) outptr[i] = inptr[i];   }
> 
>  is defined and equivalent to "out = in;".

and Doug Gwyn replies:
$ No, this can't be guaranteed. For example, there may be bits
$ in the short that are not covered by its chars.

I'm pretty sure this is wrong.  The draft proposed standard says:

* Section 1.5, page 2, lines 33-34 and 38-40:

# Byte - the unit of data storage in the execution environment large
# enough to hold a single character in the character set of the execution
# environment.
  ...

# Except for bit-fields, objects are composed of contiguous sequences
# of one or more bytes, the number, order, and encoding of which are
# implementation-defined (except where explicitly specified).

That rules out the interpretation Doug gives, and the following seems
to me to lock in the fact that the above code segments ARE equivalent
(barring interrupts):

* Section 3.1.2.5, page 20, lines 47-48:

# An object declared as a character (char) is large enough to store
# any member of the execution character set. ...

* Section 3.3.3.4, page 38, lines 13-16:

# The sizeof operator yields the size (in bytes) of its operand, which
# may be an expression or the parenthesized name of a type.
#
# When applied to an operand that has type char, unsigned char, or
# signed char, the result is 1. ...

Of course, this means that the draft proposed standard disallows any
implementation using, say, 7-bit chars and 36-bit ints, which might be
desirable on DECsystem-10's; but I think it is reasonable to do so, just
as it is reasonable to disallow non-binary machines.  Too much C assumes
the underlying model stated in section 1.5 to proceed otherwise.

Mark Brader	  "I'm not a lawyer, but I'm pedantic and that's just as good."
utzoo!sq!msb						       -- D Gary Grady



More information about the Comp.lang.c mailing list