PR# 3699 MULTI_ARRAY_LIST cannot do forth after remove

In MULTI_ARRAY_LIST, the feature forth cannot always be called after the feature remove, even when after is checked first.  The bug occurs when remove causes current_array.empty to be true.  In this case, active.item can become stale, and when forth is subsequently called, it tries to act on this stale item instead of a valid item.  Consider the following code sequences:

Failing code:
	...
	population.remove
	if NOT population.after then
		population.forth
	end
	...

Working code:

	...
	population.remove
	if idx < population.count then
		population.start
		population.go_i_th(idx)
	else
		population.start
	end
	if NOT population.after then
		population.forth
	end
	...

The working code works because it causes active to be refreshed to the correct sub-array.  Also, the Failing code works fine if population is the type ARRAYED_LIST instead of MULTI_ARRAY_LIST.

Use the code snippet shown above, and make sure that population.remove causes the current sub-array (active.item) to become empty.  Also, make sure active.item is either the first_element or last_element.

If you have trouble reproducing this, let me know and I'll try and carve out a test program from my code.

From: "John M. Long" <jlong123@mindspring.com>
To: bugs@berkeley.eiffel.com
Cc:  Subject: Re: EiffelBase/3699
Date: Tue, 13 Apr 2004 06:41:49 -0700

 ----=_tgrn7058lbot300cin2sjk7ue9cs48684s.MFSBCHJLHS
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: quoted-printable
 
 Hi,
 
 Attached, please find a "repaired" version of MULTI_ARRAY_LIST (I also =
 had to
 make a cursor class since they are paired) and also a test case that is =
 close to
 a test class based on the GOBO test class.
 
 The test is not exhaustive, but it does uncover many errors.  It is set =
 to run
 on the repaired class, but it is easy to change that.  Let me know if you=
  need
 any other information.
 
 Regards,
 
 -John M. Long
 
 
 On Tue, 16 Mar 2004 00:09:01 -0800 (PST), you wrote:
 
 >Thank you very much for your problem report.
 >It has the internal identification `EiffelBase/3699'.
 >
 >If you want to add more information to your report or
 >reply to our answer, please reply to this message
 >without modifyin
....
Output truncated, Click download to get the full message