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 09:48:18 -0700 Organization: None to speak of Lines: 64 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="8019"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+cVQzOWnU9q6FVu565GgDC" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:/1gjR4Cf1bVoTbVLQO38NoBpNwU= sha1:XE9q70AdO/qpYgKzIQJAHWsxdjc= Xref: csiph.com comp.lang.c:93732 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's assuming we can make that assumption. It's likely that there's no good reason to use anything other than two's-complement, but I'm not 100% confident that that will never change. This requires input from people who know more about this stuff than I do. And of course two's-complement representation doesn't necessarily imply the usual two's complement behavior in all cases; it tells us how negative integers are represented, but it doesn't tell us the result of evaluating INT_MAX+1 or -5<<3. That's another set of assumptions that might or might not be sensible to make in a hypothetical new standard. > At the same time, it may be useful to allow implementations > to use integer forms beyond the indicated three provided they document > such behavior. If a 32-bit platform treated 0x80000000 as a NaN, that > could be useful (providing the benefits of overflow trapping but at a > much lower cost) but extending the concept to 64 bits would be expensive > *unless* it were allowed to define INT_MIN as -0x7FFFFFFF00000000 rather > than -0x7FFFFFFFFFFFFFFF-1]. At present, however, the Standard would not > allow such behavior, thus making support for such behavior impractical > with multi-precision math. C already explicitly allows the two's-complement representation with sign bit 1 and all value bits 0 to be a trap representation. As for -0x7FFFFFFF00000000, I'm skeptical that any such systems exist or are worth considering. >> I don't even use shift operators on signed types; as far as I'm >> concerned they only make sense for unsigned types. The fact that >> they're well defined for non-negative signed values that don't >> overflow is just a (small) bonus. YMMV. > > How would you multiply a signed number by 2^N in such a fashion as to > yield defined behavior in all cases where the result would be > representable, without relying upon implementation-defined behavior? I'd probably use the "*" operator, for example -5 * (1<<3). [...] -- 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"