Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!think!ames!ptsfa!ihnp4!cuae2!killer!pollux!bobkat!m5
From: m5@bobkat.UUCP (Mike McNally )
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <2097@bobkat.UUCP>
Date: Mon, 27-Jul-87 18:20:09 EDT
Article-I.D.: bobkat.2097
Posted: Mon Jul 27 18:20:09 1987
Date-Received: Thu, 30-Jul-87 01:37:23 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <840@mcgill-vision.UUCP> <1126@nu3b2.UUCP>
Reply-To: m5@bobkat.UUCP (Mike McNally (Man from Mars))
Organization: Digital Lynx, Inc; Dallas, TX
Lines: 73

In article <1126@nu3b2.UUCP> rwhite@nu3b2.UUCP (Robert C. White Jr.) writes:
 >
 >	Oddly enough, by definition what you have used above is a valid
 >construct on just about every machine I have ever seen.  Since the low
 >order byte of a word, and the low order word of a double-word are stored
 >"above" the high-order portion you get:
 >
 >		+--------+--------+
 >       | low    | high   |
 >       +--------+--------+
 >           ^
 >           |
 >       This is the point indicated by the address-of operator
 >and if char is the size of int, it does not matter.  If char is a byte
 >and int is a word, the low order bits of the int corrispond to the
 >byte that would be union aligned of type char [etc].  By the definition
 >your code fragment WILL work [i.e. produce the correct result] wether
 >c is int or char.  [which is why the spec. tells you to use int]

Sorry, Robert, but I'm going to have to sue you.  On many machines this
is very much untrue.  Multi-byte primitive objects are stored

    +-------+-------+-------+       +-------+
    | MSB   | MSB-1 | MSB-2 | . . . | LSB   |
    +-------+-------+-------+       +-------+

The C language does not specify the byte ordering used for multi-byte
primitive data objects.

 >   On any machines which do not use this inter-position, the use
 >of pointers is massaged in the memory model to produce the same net
 >effect.  

Not on any I've ever used.  It's very simple and inexpensive to do
casts:

    int i;
    char c;

    i = c;

translates to (on a 680x0):

    MOV.B   c, D0
    EXT.W   D0      ; Maybe followed by an ext.l if ints are 32 bits

On *any* machine, something has to be done to set the value of the
upper eight bits of the int, so there is no difference in code.

 >       If this arangement, or some adaptive work-around were not
 >built into the language, the casting between types [i.e. assigning
 >the value of a sufficiently small int to a char] would produce more
 >logical shifting and adaptive work than the actual math/assignment.
 > int x; char y; x = 13 ; y = x;  would be unreasonably large.

Wrong wrong wrong.

 >   The only real problem comes down to potiner MATH, but as long
 >as aray of int/char are used consistantly that wont matter either.
 >
 >   If you dont believe me, get out your DDT and take a look.
 >   If I am wrong..... SUE ME!
 >
 >
 >Robert.

My lawyers will be in touch.

-- 
Mike McNally, mercifully employed at Digital Lynx ---
    Where Plano Road the Mighty Flood of Forest Lane doth meet,
    And Garland fair, whose perfumed air flows soft about my feet...
uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474