This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BitSet.[x]or does (not) grow BitSet

Mark Wielaard wrote:
> Hi,
> Mauve contains an AcuniaBitSetTest and a jdk10 test for
> java.util.BitSet. The first assumes that an [x]or with another BitSet
> does not grow the original BitSet, the other assumes otherwise.
> Although the API documentation is not very clear I am inclined to go
> with the assumption that the BitSet does not grow. So I would like to
> check in the following to at least make both tests behave the same.

I question your interpretation. The 1.4 docs state in the class

"This class implements a vector of bits that grows as needed... Note
that the size is related to the implementation of a bit set, so it may
change with implementation. "

> ---  1999/03/21 09:59:56     1.3
> +++  2002/04/01 00:01:59
> @@ -118,6 +118,8 @@
>         h.check( b2.toString().equals("{1, 2, 11, 15, 17, 200}") );
>         b2.xor(b2);
>         h.check( b2.toString().equals("{}") );
> +       // No way to shrink the original BitSet, so create a new one.
> +       // b2 = new BitSet();
>         b2.xor(b1);
>         b3.or(b1);
>         h.check( trulyEquals(b2,b3) );
> (Context: b1 has bit 200 set, b2.length was 300, b3 is a new BitSet with
> default length.)
> Any objections?

Your patch does nothing, as the equals() method does not take size into
account, so it does not matter whether b2 grew or not.  Instead, you
should patch AcuniaBitSetTest, because it is making blatant assumptions
about the size of a bit set which do not have to be true, according to
the specs I quoted.

This signature intentionally left boring.

Eric Blake   
  BYU student, free software programmer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]