Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C wish list Date: Wed, 20 Mar 2019 13:29:22 -0700 Organization: None to speak of Lines: 32 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="a26d008c97410be935366452bc5d340d"; logging-data="25491"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19A4D0oSaMUITkZ5EZY5+Tu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:GusF8YItptUPE7w1Osr9Q7S2LoI= sha1:xZgvIq++nYvrLteTo1FdD48XVFQ= Xref: csiph.com comp.lang.c:142125 David Brown writes: [...] > I think it would be a good idea for future C standards to fix the signed > representation as two's complement, remove all mentions of trapping > values for integer types, remove the possibility of padding bits in > these types (except perhaps for _Bool), Agreed so far (unless there are relevant real-world implementations with padding bits). > enforce either big or little > endian ordering, Nope. There are existing implementations using both representations, though little-endian has become more common. (I worked on big-endian systems as recently as last year.) Emulating a "foreign" endianness would be entirely too expensive. Big-endian hardware might die out in the next few decades, as non-two's-complement has. Once that happens, we can revisit this. > and tighten up implementation defined behaviour when > all current targets have the same behaviour. Agreed, but that would have to be studied on a case by case basis. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */