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: Is this code considered to transgress the signed overflow purism? Date: Fri, 28 Apr 2017 08:35:29 -0700 Organization: None to speak of Lines: 84 Message-ID: References: <11ea6682-cdee-4513-97c2-6c90b585716a@googlegroups.com> <87o9vi6rql.fsf@bsb.me.uk> <26aee5e9-ed2f-4c6e-af68-b85418c7e641@googlegroups.com> <6175390e-9ea6-45f9-bf8c-d87525c332da@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="2e5ec5e1f0fe87e81c65a0e293e55e1b"; logging-data="28983"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bim/998CI9gm5X9+dhpbU" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Ad21ED84sH40r9n98ykeTV9SWMs= sha1:k5kXw9/vgebNKUzqHDcltu7JgLY= Xref: csiph.com comp.lang.c:108665 joel.rees@gmail.com writes: > On Friday, April 28, 2017 at 7:21:14 AM UTC+9, Keith Thompson wrote: >> joel rees@somewhere writes: >> [...] >> > We have this coddling of brain-damaged CPUs when a left-shift on a >> > negative operand is specified on sign-magnitude architectures or >> > something, but we have this assurance that casting a -1 to an unsigned >> > fills the thing with ones. >> > >> > (I know calling it brain-damaged is too extreme, but ...) >> >> I suggest you might benefit from describing these things in less >> inflammatory terms. > > Not sure how. Well, avoiding terms like "brain-damaged" and "purism" would be a good start. >> The behavor of left-shifting a negative value is undefined. > > Without context, I suppose it is. What context? The behavior is undefined. The C standard says so. Of course an implementation can choose to define the behavior for itself. > But mapping it to a logical shift left on the CPU, whatever the CPU > gives for that, seems reasonable to me. Sure, that's a reasonable way to implement the "<<" operator, assuming that the CPU's shift operator implements the required semantics. But the C standard specifies how programs behave, not what CPU instructions are used to implement that behavior. And compilers can and do take advantage of undefined behavior to perform optimizations. If you want a language where a shift operator means "apply the CPU's logical shift instruction", you want something other than C. > Far more reasonable than assuming that casting a minus one to an > unsigned type should always result in a bit mask of the type's width. You don't have to assume it. It follows from the semantics specified by the C standard, and it's guaranteed. >> This is specified in N1570 6.5.7p4. >> >> (I don't recall that I've ever felt the need to left-shift a negative >> integer.) > > Have you even left-shifted an unsigned char expecting specifically for > the upper bits to disappear, instead of pulling the unsigned char into > and unsigned long to do the shift and then masking the upper bits back > out with a cast back to unsigned char? Not that I recall. If I needed to shift an unsigned char, I'd probably cast it to unsigned int to avoid problems. (I'm not particularly happy that that's needed.) [...] >> http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf . > > If I had the time, I'd go read it. I'm sure they thought they had a > good reason. > > I'll still push for splitting the standard if anyone is willing to > discuss it. I'd say that reading and understanding the standard (and the Rationale) is a prerequisite to making major changes. [...] Incidentally, it would be very helpful if you'd format your posts to about 72 columns. Google Groups makes it unreasonably difficult to do so. -- 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"