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: Thu, 21 Mar 2019 13:02:48 -0700 Organization: None to speak of Lines: 29 Message-ID: References: <87mulpz3qu.fsf@bsb.me.uk> <875zsdysxf.fsf@bsb.me.uk> <87zhpow44c.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="9515313518a1e23526d751bd086ff0bd"; logging-data="25093"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1926PEv2Jh7VOa9mtChHS2Y" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:VfopLIWvEdPx3uH5sjIl/hOOLdI= sha1:CNnEJn85r8BlY0XdCQs/9xDsVQ4= Xref: csiph.com comp.lang.c:142202 Ben Bacarisse writes: [...] > Interesting you left out the part I am least sure of -- padding bits. I > can imagine a scenario where memory is cheap but access is slow unless > streamlined with wide load/store operations. On such machines, an 8-bit > char might have padding bits to make it cheap to access but convenient > to program with. How would that work? It would require dropping the current requirement that the char types have no padding bits. It also implies that CHAR_BIT > 8, that an array of char requires more than 8 bits per character while still being able to represent only 256 distinct values per byte, and that an object representation can't be represented as an array of unsigned char. It would also violate the POSIX requirement that CHAR_BIT==8. I can imagine weird things in future architectures, but this is not a likely one -- unless the designers give up on C support. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */