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@classiccmp.org> wrote: > Tony Aiuto wrote: > > On Sat, Mar 6, 2021 at 11:48 PM Jim Carpenter <j...@deitygraveyard.com> > wrote: > >> On Sat, Mar 6, 2021 at 8:07 PM Tony Aiuto via cctalk > >> <cctalk@classiccmp.org> wrote: > >> > 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 > >> > > > > Well. I'm stumped right now. I verified the tape checksum again, and > even > > 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. >