From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6183 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] fix a bug in the rand48 family of prng Date: Sun, 21 Sep 2014 19:56:13 +0400 (MSK) Message-ID: References: <1411310306.4884.188.camel@eris.loria.fr> <20140921153403.GW21835@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: ger.gmane.org 1411315102 26498 80.91.229.3 (21 Sep 2014 15:58:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Sep 2014 15:58:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6196-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 21 17:58:15 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XVjWh-0007zF-Gb for gllmg-musl@plane.gmane.org; Sun, 21 Sep 2014 17:58:15 +0200 Original-Received: (qmail 10187 invoked by uid 550); 21 Sep 2014 15:58:14 -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 10179 invoked from network); 21 Sep 2014 15:58:14 -0000 In-Reply-To: <20140921153403.GW21835@port70.net> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) Xref: news.gmane.org gmane.linux.lib.musl.general:6183 Archived-At: On Sun, 21 Sep 2014, Szabolcs Nagy wrote: > * Jens Gustedt [2014-09-21 16:39:34 +0200]: > > > > This fixes a bug found by Nadav Har'El, who observed that musl was giving > > different prn sequences than other systems, even if seeded with the same > > value. > > > > The problem with something like > > > > a = lc[0] | lc[1]<<16 | lc[2]+0ULL<<32; > > > > where lc[1] is an unsigned short and int is 32bit is the following > > > > (1) lc[1] is promoted to int > > (2) the left shift 16 is performed on int > > > > the fix looks ok, but i'm not clear on why it breaks in practice UB on shift shouldn't be a problem here; I think the issue is that "lc[0] | lc[1]<<16" gets sign-extended rather than zero-extended from 32 bit to 64 bit. Alexander