From:	"A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk>
To:	DJGPP AT SUN DOT SOE DOT CLARKSON DOT EDU
Date:	Tue, 9 May 1995 11:24:07 BST
Subject:	file misreading; VERSIONS.DOC not up-to-date

   I wrote complaining about an apparent input.output bug, and I got these
replies from Stephen Turnbull:-

ST> What's the difference between [the two djgpp versions that AA mentioned]?
Version B is apparently a *lower* GO32, adds diffutls, gzip, patch, and sed,
and upgrades make. Everything else is the same. Couldn't you have put this in
table form? And got it right the first time? ... Have you gone beyond this?
gcc 2.6.0 and I believe libg++ 2.6.0 are known to be *very* buggy (not just
the new features like templates and exceptions, but breaking old features as
well), but I don't know the details. Try gcc/g++ 2.6.3 and libg++ 2.6.2 (note
version difference).

  I have just found that my Version B's file DJGPP\DOCS\DGJPP\VERSIONS.DOC
does not match reality and is out of date. Its VERSIONS.DOC says:-
  go32 1.12, binutils 2.4, bison 1.22, diffutils 2.6, flex 2.4.7, gas 2.3, gcc
2.6.0, gdb 4.12, gzip 1.2.4, libg++-2.6.0, make-3.71, patch-2.1, sed-1.18,
texinfo-3.10
  But actually (as per the names of its component *.ZIP files) version B is:-
  go32 1.12, BINUTILS 2.5.2, bison 1.22, diffutils 2.6, flex 2.4.7, GAS [NOW
IN BINUTILS], GCC 2.6.3, gdb 4.12, gzip 1.2.4, LIBG++-2.6.2, make-3.71,
patch-2.1, sed-1.18, texinfo-3.10

  Capitals are where verion B's VERSIONS.DOC is out of date. Sorry, I was in a
hurry, and I treated version B's VERSIONS.DOC as accurate, instead of checking
it against a DIR list of the directory where I put its *.ZIP files. That is
not the first time I have found VERSIONS.DOC to be out-of-date.

  (1) ST said "Try gcc/g++ 2.6.3 and libg++ 2.6.2 (note version difference).":
I did: that is my version B.
  (2) Please keep VERSIONS.DOC file UP-TO-DATE!!!!!
  (3) I will try recompiling with `-Wall' as suggested.
  (4) Herewith my original message with the version numbers corrected:-
    --------------------------------------------
  I have a very big Gnu C++ program called AAEMACS (an Emacs-type text editor
that I wrote). It compiles into an .EXE file (i.e. go32.exe + a.out) a bit
over 500,000 bytes long. It reads text as binary, looks for LF and CR-LF, and
puts each line into one link of a chained list. This involves much running of
malloc() and its C++ equivalents (i.e. new <typename>) during file-read.
  Through all its many uses and vicissitudes with all sorts of files text &
binary its input/output system never gave trouble, up to and including this
version of Gnu C (hereinafter version A)
  gcc260bn gcc260rm gas23bn gas23dc djsrc112 gcc260dc djlgr112 djdev112
fsdb091a gdb412bn gpp260 djemu112 djtst112 lgp260bn lgp260dc lgp260sr djlsr112
djdoc112 djeoe112 gdb412dc txi310bn txi310dc wmemu112 bnu24bn bnu24dc dj112m1
dj112m2
  When I recompiled AAEMACS with version A, still no trouble.
  Then I updated to this version (hereinafter version B):-
  go32 1.12, BINUTILS 2.5.2, bison 1.22, diffutils 2.6, flex 2.4.7, GAS [NOW
IN BINUTILS], GCC 2.6.3, gdb 4.12, gzip 1.2.4, LIBG++-2.6.2, make-3.71,
patch-2.1, sed-1.18, texinfo-3.10
  When I recompiled AAEMACS with version B, frequently when AAEMACS reads
files, it reads and/or prints files not properly but with short sections of
them replaced by binary rubbish. I cannot imagine easily that this is a
programming error by me, as AAEMACS has given me no trouble at all of this
sort over 4 years of very intensive use and much going through its source
form. I have now gone back to version A, and the input/output bug has gone.
  Has anyone else had input/output mishaps of this sort?
  As I said above, it <might> be a clash between input and the malloc()/new
stack.
  I regret that I am too busy at work to be very willing to wade through
AAEMACS myself right now and much recompilation with bits snipped out. Using
-g compilation mode and symify yields nothing of use.

- Raw text -