Curious compare_tests bug

[Nix <nix at esperi dot demon dot co dot uk>]

While converting my test scripts to use compare_tests instead of diff
&c, I noticed a curious presumed bug in compare_tests.

Try compare_testing a .sum file with itself.

At least on this box, this yields a bunch of differences, which is
absurd. Every failure is marked as having disappared and then
reappeared again.

Looking more closely, comm(1) appears to be spouting nonsense;
i.e., in this expression (and comparable ones) in compare_tests:

grep '^FAIL' "$now_s" | sed 's/^....:   //' >$tmp1
grep '^[PF]A[SI][SL]' "$before_s" | sed 's/^....:       //' | comm -23 $tmp1 - >$tmp2

the comm(1) call is saying that lines exist that are unique to $tmp1
even though it was generated from the same file as the stdin to comm,
as it was if you're comparing a test run to itself.

FWIW in the situation I've tested the two sed calls had no effect, and 
diff(1) said that the stdin to comm(1) had lines added that were not
present in $tmp1, but *not vice versa*.

i.e., comm, when it says that lines exist in $tmp1 that do not exist
in its standard input, is lying.

This happens at least with comm(1) from the GNU textutils-1.22 and
1.22f.

Is this my config? Has anyone else seen it? If someone else has, has
Jim Meyering been informed so that he can fix it?

If not, I'll inform him myself and fire my testcase (i.e. $tmp1 and
the stdin to comm(1) here) in his general direction.



(Hmm. It occurs to me that this could also be a bug in strcmp(3) from
 glibc-2.0.6, but the chances of a bug in strcmp(3) are *small*; it's
 torture-tested so hard.)

-- 
`Anyone who says you can have a lot of widely dispersed people hack
 away on a complicated piece of code and avoid total anarchy has never
 managed a software project.' - Andy Tanenbaum in 1992 on comp.os.minix