From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8157 Path: news.gmane.org!not-for-mail From: Pascal Cuoq Newsgroups: gmane.linux.lib.musl.general Subject: Re: Left-shift of negative number Date: Fri, 17 Jul 2015 19:55:59 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1437162984 25722 80.91.229.3 (17 Jul 2015 19:56:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jul 2015 19:56:24 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-8170-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 17 21:56:14 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZGBju-0003Q8-40 for gllmg-musl@m.gmane.org; Fri, 17 Jul 2015 21:56:10 +0200 Original-Received: (qmail 16236 invoked by uid 550); 17 Jul 2015 19:56:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16180 invoked from network); 17 Jul 2015 19:55:58 -0000 Thread-Topic: Left-shift of negative number Thread-Index: AQHQwMqaYmW1Tp/m/UOYA278qDeI9w== Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [84.14.219.2] Content-ID: Xref: news.gmane.org gmane.linux.lib.musl.general:8157 Archived-At: Jens Gustedt wrote: > Am Freitag, den 17.07.2015, 18:28 +0000 schrieb Lo=EFc Runarvot: > > According to the C11 standard, doing a left-shift on a negative > > integer is considered as an undefined behavior (6.5.7:4). >=20 > There is no such thing as "considered undefined behavior", You are right, the word =93considered=94 is unnecessary. A left shift on a negative integer is undefined behavior, period. > this is a > terminology that makes not much sense. Unfortunately the term > "undefined behavior" is often used as a synonym for "errorneous code" > which it just isn't. But in this case, it is used as a synonym for =93being undefined behavior= =94, which it is. Or are we reading the phrase =93otherwise, the behavior is und= efined=94 in the relevant clause of the standard differently? I know that this is not well-known, so perhaps I should explain: ever since the late 1990s, C compilers have been taking advantage of undefined behavio= r in the C standard to introduce new optimizations. So if you rely on undefin= ed behavior in your C programs, they may not work today, and they may break tomorrow. For instance, a claim very similar to yours: > Whereas we can > reasonably assume that a shift of a negative value in two's complement > is the same as an unsigned shift, may be used to justify that INT_MAX + 1 results in INT_MIN on two's complement platforms. This line of reasoning does not work too well nowaday= s, as anyone who has ever read the assembly generated by a modern optimizing compiler for the function int f(int x) { return x + 1 > x; } has verified f= or themselves. So what about shifts of negative values then? Should we worry that they will be broken in 2017? No, there is no need to wait. According to this post, ICC takes full advantage today of the fact that they are undefined behavior: http://stackoverflow.com/questions/22883790/left-shift-of-negative-values And according to one slide in this deck, MSVC does too(*): http://fsl.cs.illinois.edu/images/2/27/2011-09-30-CK-MVD.pdf > But this doesn't mean > that a particular implementation of a C compiler or the C library > (here musl) can't define a behavior for that. I sincerely do not think that it's not musl's place to define the behavior of -1 << 1, until it comes bundled with a C compiler, because until then, the behavior of that expression is entirely without its control and entirely within the control of unsympathetic C compilers that have the C standard on their side. Also the phrase =93strives to be correct in the sense of standards-conformance=85=94 would need to be amended to something like =93works with at least two GCC-like C compilers=94. Pascal (*) by the way, do not remember anything that these slides say about Frama-C. The authors of the slides, when talking about it, have no idea what the f-word they are talking about, and they have a research the useful= ness of which they conveniently want to impress you with.