🚀 go-pugleaf

Is there a patch or new version of GNU DIFF addressing the following
behavior?  Under SunOS 4.1.2, GNU DIFF 1.15 "diff3 -e", compiled
either with gcc 2.2.2 or cc from SunOS, gives wrong output.  This in
turn affects RCS merge operations, such as those invoked by CVS.

An example illustrates the problem.  Consider the command "diff3 -e
file1 file2 file3", intended to merge into file1 any differences
between file2 and file3.  The contents of the files are typed below.
Notice especially that file2 and file3 differ only by a single initial
line, containing X.

	file1	      file2         file3
     1		   1	         1  X
     2		   2	         2   
     3		   3	         3   
     4  a	   4    a        4   
     5  P	   5	b        5  a
     6  P	   6	b        6  b
     7  P	   7	b        7  b
     8		   8	         8  b
     9  d	   9	c        9   
    10		  10	c	10  c
    11  Q	  11	c	11  c
    12  Q	  12		12  c
    13  Q	  13	d	13   
    14		  14	e	14  d
    15  e		        15  e

The expected output of GNU diff3 is
	0a
	X
	.
an ed(1) script which would insert the X.  This is also the output
given by SunOS diff3.

In fact, the original large C++ source file from which this example
was derived could not be reduced to a simpler case than this, or GNU
diff3 would also give the expected output: for example, removing line
5 of file1; or, removing line 5 of file2 and line 6 of file3.  But the
actual output of GNU diff3 in the absence of further simplification is
	9,14c
	d
	.
	5,7c
	b
	b
	b
	
	c
	c
	c
	.
	0a
	X
	.
an ed(1) script which radically disturbs file1, actually making it
identical to file3.

In the file from which this example was taken, the wrong output of GNU
diff3 had the same effect: invoked from CVS, it not only incorporated
a couple of changes made by another programmer near the top of the
file, but it also discarded all changes made by this programmer,
replacing them with the lines in the repository.  Fortunately, this
was recognized by RCS merge as a merge overlap, so the programmer
could recover manually.

My great fear is that this behavior sometimes results in "silent" code
lossage in the CVS environment.  So far I have no evidence that this
has occurred.

-- 
Ed McGuire                   1603 LBJ Freeway, Suite 780
Systems Administrator/       Dallas, Texas 75234
 Member of Technical Staff   214/620-2100, FAX 214/484-8110
Intellection, Inc.           <ed@intellection.com>