Re: [RFC] testsuite/gdb.base/arithmet.exp: re-write

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

That sounds totally fine to me --- thanks for explaining it.

I'm not a maintainer of the test suite, but I would be happy to see
this change go in.

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> 
> Jim Blandy writes:
> 
> > Can you characterize the differences (if any) between the operations
> > GDB executes in the old and proposed new versions?
> 
> arithmet.exp operates on a program with four variables, "x" "y" "z" and "w".
> It assigns values to those variables and then does a lot of simple
> add-subtract-multiply-divide operations to check operator precedence
> and associativity.
> 
> The tests themselves are already unique (the same expression is never
> used twice) so my new version executes the same tests as the old version.
> 
> The assignment statements are different.  The old version has a lot of
> alternation between "set variable z=2", "set variable z=3", and
> "set variable z=2" again.  My new version has two groups of
> "set variable" statements and that's it.
> 
> I believe that the point of arithmet.exp is to test the expressions,
> not the assignments.  If desired, I could do the work in several phases,
> where the first phase is totally operationally compatible (and still
> has duplicate test names), so that people can be comfortable with a
> massive changeover to "gdb_test" and then operational changes can be
> reviewed separately (and much more effectively).
> 
> Also, I'm not totally happy with the way that I achieve uniqueness.
> I achieve it quietly by knowing that this kind of code is bad:
> 
>   gdb_test "set variable z=2" ""
>   gdb_test "print x-y-z" "10"
>   gdb_test "set variable z=3" ""
>   gdb_test "print x-y-z" "9"	# oops, duplicate test
> 
> So the test script gets influenced by this external constraint that
> doesn't actually get enforced when people make changes.  We live with
> it I guess.
> 
> Michael
>