From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: chastain@cygnus.com, jimb@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] testsuite/gdb.base/arithmet.exp: re-write
Date: Mon, 11 Jun 2001 21:48:00 -0000
Message-id: <200106120454.VAA09428@bosch.cygnus.com>
X-SW-Source: 2001-06/msg00227.html

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