Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Portable 16 bit binary integer write Date: Sun, 18 Sep 2016 15:33:24 -0700 Organization: None to speak of Lines: 51 Message-ID: References: <50a1e8f4-4fb3-4491-97d0-54768bf28685@googlegroups.com> <4fde1133-61ff-4045-9cbe-cccff1408ad3@googlegroups.com> <0b757bbb-0494-44cb-bd5a-26f117aaa404@googlegroups.com> <2cf666d7-0755-4c70-adad-07dbafc2b2e7@googlegroups.com> <09cb4413-16a6-4b63-89d0-9dafe56562f6@googlegroups.com> <68e53f3a-5fcc-44fc-90c4-bcf8dc3db680@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="18308"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/uJd12zUcnYxkCaCgwK6Gj" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:DY4aSp6CFwk/1BaxMeZOfNvwRg0= sha1:7lAUlVSh+XXD+xU+t3KuQoMg898= Xref: csiph.com comp.lang.c:93754 David Brown writes: > On 18/09/16 18:48, Keith Thompson wrote: >> supercat@casperkitty.com writes: >>> On Saturday, September 17, 2016 at 2:50:35 PM UTC-5, Keith Thompson wrote: >> [...] >>>> (Perhaps it's time for the next edition of the C standard to mandate >>>> 2's-complement and tighten up some of the requirements, but I think >>>> that's a separate discussion. The current standard has to cater >>>> to the three possible representations -- and represention doesn't >>>> imply a particular behavior.) >>> >>> The proper thing to do would be to recognize that implementations >>> other than two's-complement are not "normal", and require that such >>> implementations define macros to indicate their deviations from typical >>> behaviors. >> >> Too complicated. If non-two's-complement systems are really obsolete, >> why not just have the next C standard require two's-complement? If >> there are any remaining one's-complement or sign-and-magnitude systems, >> let them claim conformance to the old C11 standard, or just let them be >> non-conforming. > > That would have my vote. (But I would not want signed integer overflow > to be defined behaviour.) Drop padding bits in types too, any character > sets that don't match ASCII for the first 128 characters, Padding bits might still be sensible in some cases. For example, there have been systems in the past, presumably optimized for floating-point, that represent integers as floating-point numbers with the exponent fixed at zero (or something like that). It's worth asking whether we can drop the idea of padding bits, but I'm not ready to assume that we can do so. > CHAR_BIT that > is not 8, 16 or 32, and int sizes that are not 16 or 32 bits. 64-bit int is perfectly sensible for 64-bit systems. The main reason, I think, that it's not more common is that it leaves a gap; if you have 8-bit char and 64-int, and short is the only type in between, then you can't have both 16-bit and 32-bit integers. Extended integer types, appropriate typedefs in , should solve that, but I don't think any implementations have taken advantage of that (probably because of backward compatibility). [...] -- 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"