8 Mar
2021
8 Mar
'21
5:55 p.m.
It's a buffer overrun. sixbit_to_ascii writes 7 bytes. The extension was
declared as 4. Changing to 7 is required. I'm not sure if that is the only
fix yet. I have not had time for a detailed inspection.
- char ext[4];
+ char ext[7];
On Mon, Mar 8, 2021 at 6:57 PM Peter Coghlan via cctalk <
cctalk at classiccmp.org> wrote:
Tony Aiuto wrote:
even
On Sat, Mar 6, 2021 at 11:48 PM Jim Carpenter
<jim at deitygraveyard.com>
wrote:
On Sat,
Mar 6, 2021 at 8:07 PM Tony Aiuto via cctalk
<cctalk at classiccmp.org> wrote:
Well. I'm stumped right now. I verified the tape checksum again, and I think that is an artifact of the files being
created with the wrong
names.
For example, with tape 169249, after you skip the
UFDs, tito -t prints
(SYS) .SHR 1977-01-26 22:22 [1,4]
(SYS) .LOW 1977-01-26 22:23 [1,4]
(SYS) .SHR 1986-08-19 03:53 [1,4]
(SYS) .LOW 1975-10-24 14:52 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
All the file names are missing. That seems not right.
Very not right, because this is what tito -t is giving me:
(SYS) PIP .SHR 1977-01-26 22:22 [1,4]
(SYS) PIP .LOW 1977-01-26 22:23 [1,4]
(SYS) LOGINN.SHR 1986-08-19 03:53 [1,4]
(SYS) COBOL .LOW 1975-10-24 14:52 [1,4]
(SYS) BINCON.SAV 1964-01-02 00:01 [1,4]
(SYS) VPDATA.SAV 1964-01-02 00:01 [1,4]
Those are the first 6 after the UFDs, and extensions and
date/timestamps match yours. I don't have any, at least on 169249,
missing the first part of the file name.
Jim
got a fresh copy from
http://vtda.org/bits/software/DEC/PDP-10/tymshare/
.
That is not the problem.
I'm building tito on a generic Debian linux (x86_64, debian 4.19, gcc
8.3.0) so I doubt this is a portability problem. I'll try again next
weekend.
Out of curiosity, I tried building tito on VMS (with DECC V7.3-009 on an
Alphaserver 800). I had some errors compiling memory.c but it appears
the code involved does not get called by tito so this didn't cause me
any problems. I was able to list the contents of tape 169249 with the
resulting executable and the output I got matched the "right" output
above exactly. I didn't see anything that looked wrong elsewhere in the
file listing either.
Regards,
Peter Coghlan.