Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Recasting data as long ints and chars Date: Tue, 12 Dec 2017 17:10:15 -0800 Organization: None to speak of Lines: 21 Message-ID: References: <87efopstrv.fsf@bsb.me.uk> <87fu90mw6q.fsf@bsb.me.uk> <87d143k9e1.fsf@bsb.me.uk> <14162525-3bee-47a1-81f5-453a59e8c401@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="50e352b03c9870c864aa96ff340b6923"; logging-data="20253"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18V/RIvtkBZnNCxvmziW4TK" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:3vMc86xUnSTVZMiBpkYbXI3K2CA= sha1:s+wKlS95HoERZzgEKeUDmSUWR6s= Xref: csiph.com comp.lang.c:124259 supercat@casperkitty.com writes: [...] > On practical implementations that support uint8_t and uint32_t, > setting a uint32_t to 0x03020100 will cause one bytes to be set to > the values 0, 1, 2, and 3, in LSB-first order. I think what you mean is that the bit ordering within bytes is expected to be the same as the bit ordering within a 32-bit word (though the standard doesn't require that). It's very easy to read what you wrote as an assertion that all practical implementations are little-endian (and in fact that's how I initially read it). [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"