From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8159 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Left-shift of negative number Date: Fri, 17 Jul 2015 17:28:58 -0400 Message-ID: <20150717212858.GC1173@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1437168562 20565 80.91.229.3 (17 Jul 2015 21:29:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jul 2015 21:29:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8172-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 17 23:29:15 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 1ZGDBz-00059u-3Q for gllmg-musl@m.gmane.org; Fri, 17 Jul 2015 23:29:15 +0200 Original-Received: (qmail 19555 invoked by uid 550); 17 Jul 2015 21:29:13 -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 19520 invoked from network); 17 Jul 2015 21:29:12 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8159 Archived-At: On Fri, Jul 17, 2015 at 06:28:00PM +0000, Loïc Runarvot wrote: > > According to the C11 standard, doing a left-shift on a negative > integer is considered as an undefined behavior (6.5.7:4). > > This undefined behavior occurs in files src/multibyte/internal.c and > src/multibyte/internal.h. At line 21 in the header > (http://git.musl-libc.org/cgit/musl/tree/src/multibyte/internal.h?id=0f9c2666aca95eb98eb0ef4f4d8d1473c8ce3fa0#n21), > the implementation of the macro-definition R allow to have a > negative value on the expression ((a == 0x80) ? 0x40-b : -a) << 23. > > In fact, in the source file, at the line 11 > (http://git.musl-libc.org/cgit/musl/tree/src/multibyte/internal.c?id=0f9c2666aca95eb98eb0ef4f4d8d1473c8ce3fa0#n11). > During the application of the macro-definition R(0x90, 0xc0), we > have a != 0x90, so it's try to do (-0x90) << 23, which is an > undefined behavior. Thank you. Reporting of such issues is very welcome, as it is the intent in musl to avoid undefined behavior regardless of whether it's believed to cause problems with current compilers. The cleanest solution is probably to use unsigned arithmetic here (e.g. replace -a with 0u-a or -(unsigned)a) but I'd like to look at the code in more detail again and check all of the consequences before committing to a particular approach to fixing it. > This bug was found in the context of the libc cross-testing project > (a post blog has been written on this subject yesterday: > http://trust-in-soft.com/the-libc-cross-testing-project) The link doesn't seem to be working for me. I'd like to hear more about this project, so please let me know if there's somewhere else I can find info or if there's a corrected link that works. Rich