Bug 10578

Summary: [xcalc] uses wrong order of operations in infix mode
Product: xorg Reporter: Brice Goglin <brice.goglin>
Component: App/otherAssignee: Matthieu Herrb <matthieu.herrb>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: jeremyhu
Version: 7.2 (2007.02)Keywords: love
Hardware: Other   
OS: All   
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93665
Whiteboard: 2011BRB_Reviewed
i915 platform: i915 features:

Description Brice Goglin 2007-04-09 11:17:29 UTC
Bug reported by Maciej Kalisiak on the Debian BTS 6 years ago, still applies to latest xcalc:

It appears there's a horrible (in that xcalc is potentially misleading SO MANY
users with wrong results) bug in the way it does order of operations in the
"infix" mode.  Consider:
	2*3-3*2+1=
	
The solution, if we are to follow order of operations, is +1.  xcalc reports
-1.

I took a peek at the code, and the problem seems to be in math.c, in equf().
It computes the final solution by performing the remaining calculations (at
this point the multiplications have been performed and the results pushed on
the number stack) from RIGHT TO LEFT, no matter what, which is just plain
wrong.  In the specific example it's computing:
	6-6+1
as
	6-(6+1)

Reversing the direction of the final computation is not the correct solution
either.  Consider
	2*3-3*2*3
When the '=' is pressed, the expression that equf() gets to evaluate, I think,
will be:
	6-6*3
which should be done in right to left order.

Overall the mechanism for doing infix calculation in xcalc seems to be
seriously broken.
Comment 1 Adam Jackson 2018-06-12 19:10:34 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.

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.