Re: cbmconvert is now on GitHub

From: Marko Mäkelä <msmakela_at_gmail.com>
Date: Sun, 15 May 2022 17:58:17 +0300
Message-ID: <YoEVCRO+I0GQ9M5C_at_jyty>
Sun, Dec 05, 2021 at 02:14:17PM +0200, Marko Mäkelä wrote:
>Sat, Nov 13, 2021 at 04:44:25PM +0200, Marko Mäkelä wrote:
>>I just created a repository for my Commodore file format conversion 
>>tool that was last updated in 2006:
>>https://github.com/dr-m/cbmconvert/
>
>The first new release is out, with some minor improvements:
>https://github.com/dr-m/cbmconvert/releases/tag/cbmconvert-2.1.4
The second release is out, with some bug fixes:
https://github.com/dr-m/cbmconvert/releases/tag/cbmconvert-2.1.5

The previous release cbmconvert-2.1.4 is packaged in Debian and NetBSD, 
and I hope that the 2.1.5 release will follow soon.

I spent some effort to expand regression tests. I was a little surprised 
how many bugs have been there all these years. When I was younger, I 
thought that it is possible to be create bug-free simple programs by 
being careful. This exercise taught me that it really is not the case. 
The nice thing is that code coverage instrumentation can be combined 
with other instrumentation, such as -fsanitize=address and 
-fsanitize=undefined. I found and fixed some memory management errors 
while writing tests to cover more code.

The language of CTest is somewhat clumsy, but I think it is adequate for 
this. For example, it apparently cannot write a NUL byte in to a file, 
because it is unable to create a string that contains a NUL byte. It 
also seemed to have trouble writing a semicolon to a file.

But, who am I to criticize? Also Commodore was inconsistent; REL files 
use 0xff as an end-of-record marker (followed by NUL bytes until the end 
of the record), while data blocks in tape images use NUL byte (followed 
by whatever contents of the remaining part of the tape buffer).

Best regards,

	Marko
Received on 2022-05-15 18:00:08

Archive generated by hypermail 2.3.0.