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