From mla_strick@att.net  Wed Mar 23 11:01:41 2011
Return-Path: <mla_strick@att.net>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 1B8AE106564A
	for <freebsd-gnats-submit@freebsd.org>; Wed, 23 Mar 2011 11:01:41 +0000 (UTC)
	(envelope-from mla_strick@att.net)
Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163])
	by mx1.freebsd.org (Postfix) with SMTP id A46948FC0A
	for <freebsd-gnats-submit@freebsd.org>; Wed, 23 Mar 2011 11:01:40 +0000 (UTC)
Received: from [98.139.212.146] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 23 Mar 2011 10:48:55 -0000
Received: from [98.139.212.230] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 23 Mar 2011 10:48:55 -0000
Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 23 Mar 2011 10:48:55 -0000
Received: (qmail 86110 invoked from network); 23 Mar 2011 10:48:54 -0000
Received: from mist.nodomain (mla_strick@69.228.90.112 with login)
        by smtp110.sbc.mail.mud.yahoo.com with SMTP; 23 Mar 2011 03:48:54 -0700 PDT
Received: from mist.nodomain (localhost [127.0.0.1])
	by mist.nodomain (8.14.4/8.14.4) with ESMTP id p2NAmqmG004450;
	Wed, 23 Mar 2011 03:48:52 -0700 (PDT)
	(envelope-from mla@mist.nodomain)
Received: (from dan@localhost)
	by mist.nodomain (8.14.4/8.14.4/Submit) id p2NAmqMY004449;
	Wed, 23 Mar 2011 03:48:52 -0700 (PDT)
	(envelope-from mla)
Message-Id: <201103231048.p2NAmqMY004449@mist.nodomain>
Date: Wed, 23 Mar 2011 03:48:52 -0700 (PDT)
From: Dan Strick <mla_strick@att.net>
Reply-To: Dan Strick <mla_strick@att.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc: dan@mist.nodomain
Subject: bc sometimes mangles hexidecimal numbers
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         155886
>Category:       bin
>Synopsis:       bc(1) sometimes mangles hexidecimal numbers
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 23 11:10:01 UTC 2011
>Closed-Date:    
>Last-Modified:  Tue Apr 12 08:30:10 UTC 2011
>Originator:     Dan Strick
>Release:        FreeBSD 8.1-RELEASE i386
>Organization:
none
>Environment:
System: FreeBSD mist 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Sat Aug 14 09:15:14 PDT 2010 root@mist:/usr/src/sys/i386/compile/MIST i386
>Description:
	The bc program sometimes mangles hexidecimal numbers.
	I don't really understand what it is doing, but it seems to be
	incorrect and when it does this it is worse than useless.
	See below for a reasonably simple example.
>How-To-Repeat:
	Enter the following, beginning at a shell prompt:
		% /usr/bin/bc
		obase=16
		ibase=16
		.1F9A6B50B0F27C00

	The bc program responds:
		bc 1.06
		Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
		This is free software with ABSOLUTELY NO WARRANTY.
		For details type `warranty'. 
		.1F9A6B50B0F27B

	In other words, I enter the number:
		.1F9A6B50B0F27C00
	and it responds:
		.1F9A6B50B0F27B

	I did a little more experimentation.  If I set ibase to a
	value greater than decimal 10 and enter:
		.1
	the bc program responds:
		0

	The value of obase does not seem to matter.

>Fix:
	unknown
>Release-Note:
>Audit-Trail:

From: Stefan Eggers <coloncolonone@googlemail.com>
To: bug-followup@freebsd.org, mla_strick@att.net
Cc:  
Subject: Re: bin/155886: bc(1) sometimes mangles hexidecimal numbers
Date: Thu, 7 Apr 2011 00:21:04 +0200

 --bcaec51f991ff1910104a0476a50
 Content-Type: text/plain; charset=ISO-8859-1
 
 This seems to be somewhat similar to Debian Bug 84995 where one can find
 some explanations: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=84995
 
 When I append more and more zeros to your example input number, I finally
 get the exact output.  And another thing I noticed is that the output number
 seems to always be shorter than the input number.  Tested this with
 8.2-RELEASE.
 
 Stefan.
 
 --bcaec51f991ff1910104a0476a50
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 <div><div>This seems to be somewhat similar to Debian Bug 84995 where one c=
 an find some explanations: <a href=3D"http://bugs.debian.org/cgi-bin/bugrep=
 ort.cgi?bug=3D84995">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D849=
 95</a></div>
 
 <div><br></div><div>When I append more and more zeros to your example input=
  number, I finally get the exact output. =A0And another thing I noticed is =
 that the output number seems to always be shorter than the input number. =
 =A0Tested this with 8.2-RELEASE.</div>
 
 <div><br></div><div>Stefan.</div></div>
 
 --bcaec51f991ff1910104a0476a50--

From: Dan Strick <mla_strick@att.net>
To: bug-followup@freebsd.org, coloncolonone@googlemail.com, mla_strick@att.net
Cc:  
Subject: Re: bin/155886: bc(1) sometimes mangles hexidecimal numbers
Date: Sun, 10 Apr 2011 02:37:10 -0700 (PDT)

 >
 > This seems to be somewhat similar to Debian Bug 84995 where one can find
 > some explanations: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=84995
 > 
 > When I append more and more zeros to your example input number, I finally
 > get the exact output.  And another thing I noticed is that the output number
 > seems to always be shorter than the input number.  Tested this with
 > 8.2-RELEASE.
 >
 
 Uh, ok ... so what should be done about this bug?  Should it be reported
 to someone?
 
 Dan Strick
 mla_strick@att.net

From: Dan Strick <mla_strick@att.net>
To: bug-followup@freebsd.org, coloncolonone@googlemail.com, mla_strick@att.net
Cc:  
Subject: Re: bin/155886: bc(1) sometimes mangles hexidecimal numbers
Date: Tue, 12 Apr 2011 01:11:57 -0700 (PDT)

 > This seems to be somewhat similar to Debian Bug 84995 where one can find
 > some explanations: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=84995
 
 I took a look at the Debian bug report.  The author of the bc program
 explains:
 
 >   This is a result of having the number stored in base 10 and then
 > using other bases in the fractional values.  I can't quote the
 > posix document, but I'm sure this is legal behavior.
 
 The behavior may be "legal" (i.e. consistent with POSIX.2?), but it is
 sufficiently counterintuitive as to require specific mention on the bc
 man page.  In other words, this behavior is either a program bug or a
 documentation bug.  It cannot be neither.
 
 Dan Strick
>Unformatted:
