[comp.sources.games.bugs] Ularn bug -- selling the same gem more than once

kcr%rushforth@Sun.COM (Kevin Rushforth) (07/10/89)

There is a bug in larn that was carried over into Ularn which allows
one to sell a gem an unlimited number of times.  To reproduce this
bug, follw these simple steps:

	1. Enter the bank with one or more gems in your possesion
	2. Note the inventory letter of each gem
	3. Exit the bank
	4. drop all your gems
	5. Enter the bank -- notice that no gems are listed by the bank
	   that you can sell.
	6. Sell them anyway (using the same inventory letters that you
	   wrote down in step 2).
	7. Exit the bank
	8. pick up the gems
	9. repeat steps 1-8 until you have enough money to buy the lance
	   of death (or whatever else you need).

Following is a fix for this bug.  It is a patch that should be applied
to store.c -- this patch works for larn as well as Ularn.

------------------------------cut here------------------------------
*** store.c.old	Sun Jul  9 12:42:33 1989
--- store.c	Fri Jul  7 22:39:28 1989
***************
*** 536,541 ****
--- 536,544 ----
  
  	if (level==8) c[TELEFLAG] = 0;
  
+ 	for(i = 0; i < 26; i++)
+ 		gemvalue[i] = 0;
+ 
  	for (k=i=0; i<26; i++)
  		switch(iven[i]) {
  		case OLARNEYE: 
------------------------------cut here------------------------------

-- 
Kevin C. Rushforth                   | "If winning is not important,
Sun Microsystems                     |  then commander, why keep score?"
                                     |              - Lt. Worf
ARPA: kcr@sun.com                    |
UUCP: <most-backbone-sites>!sun!kcr  |

adb@bu-cs.BU.EDU (Adam Bryant) (07/11/89)

In article <114443@sun.Eng.Sun.COM> kcr%rushforth@Sun.COM (Kevin Rushforth) writes:
>There is a bug in larn that was carried over into Ularn which allows
>one to sell a gem an unlimited number of times.  To reproduce this

>Following is a fix for this bug.  It is a patch that should be applied
>to store.c -- this patch works for larn as well as Ularn.
>

You really don't need to create the extra loop to fix that bug.
The array gemvalue is declared as a static array and therefore saves
its value between calls to the function.

Simply remove the word 'static' from the declaration of gemvalue
and the problem will be solved.

adam

kcr%rushforth@Sun.COM (Kevin Rushforth) (07/12/89)

In article <34458@bu-cs.BU.EDU> adb@bu-cs.bu.edu (Adam Bryant) writes:
>In article <114443@sun.Eng.Sun.COM> kcr%rushforth@Sun.COM (Kevin Rushforth) writes:
>>There is a bug in larn that was carried over into Ularn which allows
>>one to sell a gem an unlimited number of times.  To reproduce this
>
>You really don't need to create the extra loop to fix that bug.
>The array gemvalue is declared as a static array and therefore saves
>its value between calls to the function.
>
>Simply remove the word 'static' from the declaration of gemvalue
>and the problem will be solved.

Not quite.  Here is the relevant piece of store.c

------------------------------
static short gemorder[26]={0};	/* the reference to screen location for each */
static long gemvalue[26]={0};	/* the appraisal of the gems */

obanksub()
{
	long amt;
	register int i,k;
	ointerest();	/* credit any needed interest */

	if (level==8) c[TELEFLAG] = 0;

/****** HERE IS THE LOOP TO INITIALIZE THE ARRAY ******/
	for(i = 0; i < 26; i++)
		gemvalue[i] = 0;
/****** END OF THE LOOP TO INITIALIZE THE ARRAY ******/

	for (k=i=0; i<26; i++)
		switch(iven[i]) {

[...more stuff...]

Since the array is declared outside the obanksub() routine, removing
the word static would not change the fact that the array keeps its
value between calls to the function.  All that it would do is make the
global array gemvalue[] externally visible (not a good idea unless you
have a reason).  Even if you were to move the array declaration into
the obanksub() function and then remove the 'static' keyword, you would
still have to initialize it.  Automatic variables in "C" (including
arrays) are not initialized upon entry into a function.  The patch that
I posted is the easiest way around the bug without modifying the logic
of the routine.

-- 
Kevin C. Rushforth                   | "If winning is not important,
Sun Microsystems                     |  then commander, why keep score?"
                                     |              - Lt. Worf
ARPA: kcr@sun.com                    |
UUCP: <most-backbone-sites>!sun!kcr  |