From:	sjk AT newmedia DOT no (Sven-J=?ISO-8859-1?Q?=F8=0D?= rgen Karlsen)
Subject:	BUG: RCS truncates files (possible stdio bug)
14 Apr 1998 09:16:29 -0700 :
Message-ID:	<upvinmkeq.fsf.cygnus.gnu-win32@newmedia.no>
Mime-Version:	1.0
To:	gnu-win32 AT cygnus DOT com

--Multipart Mon Apr 13 08:45:58 1998
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Anybody managed to build a working RCS?  I have been trying to build it=0D=

for a while, but ran into a rather ugly bug described below. I have seen=0D=

the truncation problem mentioned before (about a month ago) on this=0D
list, but the previuos poster was not able to reproduce the problem.=0D
=0D
Environment: Windows NT 4.0 SP3 =0D
	     "uname -a" =3D> CYGWIN32_NT KARLSEN 4.0 19.1 i586 unknown=0D
(Also experienced with b18.)=0D
All mounts binary.=0D
=0D
Package: RCS 5.7 sources from ftp.gnu.ai.mit.edu.=0D
Summary: ci truncates latest rev. to 1024 bytes when inserting text=0D
	 into the first 1024 bytes of the working file.=0D
Build:	 Configure and compilation runs (seemingly) without errors after=0D=

	 applying the 2 changes mentioned in M. Hirmke's package report,=0D
	 Message-ID: <6qrVmni$pfB AT mike DOT franken DOT de>.=0D
=0D
Reproduction: =0D
Input files: rcsbug.txt.org. Optionally, use the enclosed=0D
shell-script prepare-ci-bug.sh which I made to automate exposure of this=0D=

bug.  To use it, first edit the RCS_BIN variable to the location of your=0D=

RCS executables.  =0D
=0D
$ export RCSINIT=3D-x =0D
=0D
(Eliminates the use of ",v" suffixes on RCS files, I can't have path=0D
names with ',' in them because of Win95 compatibility.)  (I even tried=0D=

without it, got a messed up file name, ",rcsbug.txt," in the current=0D
directory and the first co failed.  Could this be related to the=0D
readlink() bug previously mentioned in the mailing list, and supposedly=0D=

fixed with latest cygwinb19.dll?)  =0D
Put rcsbug.txt.org in a directory. Make an "RCS" subdirectory: =0D
=0D
$ mkdir RCS =0D
$ cp rcsbug.txt.org rcsbug.txt=0D
=0D
Put location of cygwin32-compiled RCS execuatbles first in your path,=0D
or spell the path out explicitly, e.g. /h/src/rcs-5.7/src/ci.exe.  =0D
=0D
$ ci -u rcsbug.txt =0D
$ co -l rcsbug.txt =0D
=0D
Edit the working file by adding some text before the 1024th=0D
position. See the enclosed shell script for an example.  The edits done=0D=

by the script consist of adding 5 lines at about pos. 800, that is, the e=
nd of=0D
the line consisting of 'm'-s.  The size of the inserted text doesn't=0D
seem to matter, I have tried sizes from around 100 to >1200 bytes with=0D=

similar results. The byte position doesn't seem to matter, as long as=0D
it's less than 1024. =0D
=0D
$ ci -u rcsbug.txt=0D
=0D
The latest rev. in the RCS file RCS/rcsbug.txt is now truncated to=0D
exactly 1024 bytes, which can be easily seen by checking the file out=0D
again: =0D
=0D
$ co -l rcsbug.txt=0D
=0D
Fine print: I have debugged (using gdb) this down to the 'putdftext'=0D
routine in the file src/rcsgen.c. The getc/putc (the macros from=0D
rcs/rcsbase.h basicly expands to this + error checks) loop at lines=0D
660-664 terminates prematurely because getc() returns EOF after exactly=0D=

1024 iterations (the __SFEOF bit is set in the '_flags' member of the=0D
'__SFILE' struct corresponding to the input file). This indicates that=0D=

there might be a bug in cygwin32's putc() implementation.=0D
=0D
Ideally, I would like to reproduce all file IO done by RCS in a=0D
separate test program to isolate the bug further, but this seems too=0D
tedious and time-comsuming at the moment. I would appreciate if someone=0D=

could test/confirm this and maybe track the bug down to either cywin32 or=
=0D
RCS.=0D
=0D
Thanks for great software and mailing list.=0D
=0D
Sven-J=F8rgen =0D
=0D
rcsbug.txt.org:=0D
--Multipart Mon Apr 13 08:45:58 1998
Content-Type: text/plain; charset=US-ASCII

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
--Multipart Mon Apr 13 08:45:58 1998
Content-Type: text/plain; charset=US-ASCII


prepare-ci-bug.sh:
--Multipart Mon Apr 13 08:45:58 1998
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

#! /bin/sh
RCS_BIN=/h/src/rcs-5.7/src	# Location of RCS executables.
# Line where sed insert $INSERT_STRING
INSERT_LINE=16
# The sed replacement string. Note that "\\" is sed's newline.
INSERT_STRING="\\
Here we insert some text at pos. < 1024 bytes to show \\
the truncation bug. After this editing, a \"ci -u\" on this file\\
will result in the file being truncated to exactly 1024 bytes.\\
"

TESTFILE_ORG=rcsbug.txt.org
TESTFILE=rcsbug.txt
CI_OPTIONS="-u -t-Test"   # -u: Leave working file,
			  # -t-: Desc. for the new RCS file (automates prompt).

CO_OPTIONS=-l			# -l: Check out locked.

# Cleanup from previous runs.
if [ -e "RCS" ]; then rm -f RCS/*; fi

cp -f $TESTFILE_ORG $TESTFILE
$RCS_BIN/ci.exe $CI_OPTIONS $TESTFILE
$RCS_BIN/co.exe -l $TESTFILE

sed "${INSERT_LINE}i\\
$INSERT_STRING" $TESTFILE_ORG > $TESTFILE
--Multipart Mon Apr 13 08:45:58 1998
Content-Type: text/plain; charset=US-ASCII


-- 
Two is not equal to three, even for large values of two.
--Multipart Mon Apr 13 08:45:58 1998--

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -