Bug 665 - bugs in xcalc -rpn mode
Summary: bugs in xcalc -rpn mode
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/other (show other bugs)
Version: 6.7.0
Hardware: All All
: low minor
Assignee: Alan Coopersmith
QA Contact:
URL: http://rle-vlsi.mit.edu/people/gjcora...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-24 05:59 UTC by Alan Coopersmith
Modified: 2004-07-05 09:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
fix usage of localeconv()->decimal_point (856 bytes, patch)
2004-07-06 02:18 UTC, Alexander Gottwald
no flags Details | Splinter Review

Description Alan Coopersmith 2004-05-24 05:59:44 UTC
[Originally reported by Geoffery Coram, then of MIT, to various vendors, 
 including Sun Solaris bug id 4303332 and RedHat bugzilla id #7795. See
 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=7795 for some additional
 details.]

If you run xcalc -rpn and enter the following sequences, you will note the
results given are wrong as noted (you may need to hit ON to clear the stack
between tests):

1) From the man page:

  BUGS
       HP mode:  A bug report claims that the sequence of keys 5,
       ENTER, <- should clear the display, but it doesn't.

This is how _my_ HP calculator works.  Admittedly, it's an 11C
rather than the 10C that's supposedly being emulated, but I
think the behavior is the same.

2) If you use the backspace in rpn mode to erase a decimal
point, the flag that prevents two decimals in a number is
not cleared, so you can't enter the decimal point after
correcting it.

3) Try 5 ENTR 2 ENTR .1 * +
you'll get 2.2 instead of 5.2 (the 2 is duplicated on the stack
because ".1" is less than 1)

4) Try 5 PI *
you'll get zero instead of 15.707963 (the PI function does
not push 5 onto the stack)

5) Also, if you store a number in location 1
5 STO 1
then recall the number and type 2
RCL 1  2
you'll get 52 (instead of 5 and 2 on the stack), because the RCL
function is confused.
Comment 1 Alan Coopersmith 2004-05-24 06:05:10 UTC
Fix committed to CVS head:

Changes by:	alanc@pdx.	04/05/23 13:03:49

Log message:
  2004-05-23  Alan Coopersmith  <alan.coopersmith@sun.com>
  	* xc/programs/xcalc/math.c
  	* xc/programs/xcalc/xcalc.man
  	Bugzilla #665: xcalc -rpn mode errors  (Geoffery Coram)

Modified files:
      ./:
        ChangeLog 
      xc/programs/xcalc/:
        math.c xcalc.man 
  
  Revision      Changes    Path
  1.37          +6 -1      xc/ChangeLog
  1.3           +28 -11    xc/programs/xcalc/math.c
  1.3           +3 -2      xc/programs/xcalc/xcalc.man


Comment 2 Alexander Gottwald 2004-06-25 07:44:47 UTC
from line 403:
	  if (dispstr[strlen(dispstr)-1] == '.')
             Dpoint=0;
#ifdef X_LOCALE
	  if (dispstr[strlen(dispstr)-1] == localeconv()->decimal_point)
             Dpoint=0;
#endif	  

This is broken. localeconv() is from <locale.h> which is _NOT_ included if
X_LOCALE is defined resulting in a compile error.

One solution (just fixing the bug) is
	  if (dispstr[strlen(dispstr)-1] == '.')
             Dpoint=0;
#ifndef X_LOCALE
	  if (dispstr[strlen(dispstr)-1] == localeconv()->decimal_point)
             Dpoint=0;
#endif

another (in analogy to similar code on line 436)

#ifndef X_LOCALE
	  if (dispstr[strlen(dispstr)-1] == localeconv()->decimal_point)
             Dpoint=0;
#else
	  if (dispstr[strlen(dispstr)-1] == '.')
             Dpoint=0;
#endif	    
Comment 3 Alexander Gottwald 2004-07-06 02:18:18 UTC
Created attachment 440 [details] [review]
fix usage of localeconv()->decimal_point

decimal_point is a const char* not char. the patch uses strcmp instead of plain
char == char operator and allows decimal_point to be of any length.
localeconv() is only called if X_LOCALE is _not_ defined
Comment 4 Alexander Gottwald 2004-07-06 02:25:25 UTC
/cvs/xorg/xc/ChangeLog,v  <--  ChangeLog
new revision: 1.83; previous revision: 1.82
/cvs/xorg/xc/programs/xcalc/math.c,v  <--  math.c
new revision: 1.4; previous revision: 1.3

marked as fixed


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.