Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!whuxl!whuxlm!akgua!gatech!seismo!mcvax!boring!guido From: guido@boring.UUCP Newsgroups: net.lang.c Subject: Re: Byte order (retitled) Message-ID: <6880@boring.UUCP> Date: Sun, 20-Apr-86 12:16:34 EST Article-I.D.: boring.6880 Posted: Sun Apr 20 12:16:34 1986 Date-Received: Wed, 23-Apr-86 13:56:26 EST References: <7046@cca.UUCP> <7158@cca.UUCP> <1104@psivax.UUCP> Reply-To: guido@mcvax.UUCP (Guido van Rossum) Organization: "Stamp Out BASIC" Committee, CWI, Amsterdam Lines: 26 Apparently-To: rnews@mcvax In article <1104@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > Could you expand on this! Do you mean that if you cast a >pointer to a long to a pointer to a short and dereference you will get >the *high* order portion on a big-endian machine and the *low* order >portion on a little-endian? Clearly a portability problem, and the the >big-endian behavior is counter-intuitive. You're right. Casting "pointer to long" to "pointer to short" in C has a portability problem. This can't be solved by outlawing big-endian architectures, nor by 'fixing' the C compilers. Non-portable casts have have an effect that is obvious or at least understandable when you know the underlying hardware architecture of a given implementation; never mind intuitivity, and you correctly describe the effect of this particular example. If you want to write portable C, don't use non-portable constructs. If you want to flame big-endianness, don't use C portability as an argument. You're right about the counter-intuitivity of the effect of dereferencing a wrong-size pointer in assembly language, and (as has been said numerous times by now) this was one of the resons for its use in the PDP-11. -- Guido van Rossum, CWI, Amsterdam