From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH URGENT] common/vsprintf: Fix signed->unsigned error, causing glacial performance. Date: Tue, 12 Nov 2013 17:04:34 +0000 Message-ID: <52825FA2.8030405@citrix.com> References: <1384272621-21655-1-git-send-email-andrew.cooper3@citrix.com> <5282640502000078001028D1@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VgHOS-0006dh-7r for xen-devel@lists.xenproject.org; Tue, 12 Nov 2013 17:04:48 +0000 In-Reply-To: <5282640502000078001028D1@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 12/11/13 16:23, Jan Beulich wrote: >>>> On 12.11.13 at 17:10, Andrew Cooper wrote: >> The original patch for >> >> c/s 67a3542c5bc356e6452d8305991617c875f87de4 >> "common/vsprintf: Refactor string() out of vsnprintf()" >> >> specifically used signed integers, identical to the code copied out of >> vsprintf. >> >> When committed, these had changed to unsigned integers, which causes a >> functional change. This causes glacial boot performance and an excessive >> quantity of spaces printed to the serial console, as we loop to the upper >> bound of a 32bit integer. >> >> Signed-off-by: Andrew Cooper > Considering that I had changed those on the fly while committing, > I committed this one without waiting for an ack. But ... > >> --- a/xen/common/vsprintf.c >> +++ b/xen/common/vsprintf.c >> @@ -239,7 +239,7 @@ static char *number( >> static char *string(char *str, char *end, const char *s, >> int field_width, int precision, int flags) >> { >> - unsigned int i, len = strnlen(s, precision); >> + int i, len = strnlen(s, precision); > ... this just looks _so_ wrong (and whenever I'll come across > this again, I'll just be tempted again to adjust it)! > > Jan > I agree in general, and do err on the side of unsigned whenever possible. In this case, I went with exactly what was present before. ~Andrew