Getting list.c to work

Par Briqunullus

Champion (433)

Portrait de Briqunullus

03-08-2021, 21:27

I wanted to use Vincent van Dam's list utility to batch convert basic listings to text files. Unfortunately the .exe file is 16 bit and can't be used in Windows 10 anymore. So I compiled it with gcc. It works, but it has some strange behavior. During the list, the program suddenly goes astray and starts printing null characters forever. Like:

1020 IFS=3ANDX<240THENX=X+2:R=1:RX=1:GOTO1060
1030 IFS=7ANDX>=0THENX=X-2:R=0:RX=-1:GOTO1060
1040 GOTO 980
-257 (null)(null)(null)

Or:

200 GOSUB230
210 '-------------------------------------------------------GEEN GEGEVENS
220 SCREEN1:WIDTH32:LOCATE(null)(null)(null)

I don't think Vincent's code is to blame. But I can't figure out what's happening either. Does anyone have a working list.exe for me?

!login ou Inscrivez-vous pour poster

Par Pencioner

Scribe (1480)

Portrait de Pencioner

03-08-2021, 23:08

I just did it (i'm using Archlinux 64bit) with gcc 11.1.0 and with a few files i tried - all works as it should. If you send me a failing file i can check if it works in my case. Anyway, try to compile with disabling optimizations, it helps sometimes. Otherwise there might be something with different integer types sizeof? (if it was made for 16bit systems, maybe there are some issues with that, as we are 64bit now)

Par Briqunullus

Champion (433)

Portrait de Briqunullus

05-08-2021, 20:02

So I was using an older version of gcc. I have updated, my .exe nearly doubled in size, but the problem persists. I think you are correct on that old code vs. modern compiler remark. I have sent you the two listings shown above. Could you please test listing them for me?

If they work for you, I think I will switch to Linux for running this tool.

Par Pencioner

Scribe (1480)

Portrait de Pencioner

05-08-2021, 21:55

You listings are working fine with list.c compiled under Linux
I tried to compile them under CygWin and it works as well (gcc version 10.2.0). If you don't know what CygWin is - in short, it is a compatibility layer/DLL to compile and run GNU/Linux/Posix tools under Windows but without virtualization (natively). Sometimes it is very useful. So i think if you want to work under Windows but sometimes want to use bash console with some Linux commandline, and/or compile you code with all the Linux settings - you might be interested - check https://www.cygwin.com/ - i use it for a long time and it makes life easier sometimes :)

Par Briqunullus

Champion (433)

Portrait de Briqunullus

05-08-2021, 22:27

Thanks for testing these. So it's the compiler setup after all, I'm not surprised. I didn't suspect Vincent's code nor the basic listings themselves. Big smile

I took gcc from winlibs.com, that uses MinGW-w64. It's been years since I last used gcc, so I'll have to dive into that and how to setup on Windows properly. Thanks for the starting points you gave me.

Par Pencioner

Scribe (1480)

Portrait de Pencioner

05-08-2021, 22:43

Briqunullus wrote:

Thanks for testing these. So it's the compiler setup after all, I'm not surprised. I didn't suspect Vincent's code nor the basic listings themselves. Big smile

If you ask me, carefully written C code will be portable as it will never depend on size of default types which might be different from platform to platform. Though i'm not blaming Vincent for not having an industrial grade code because i believe he had no plans to support it for so many years, hehe Wink I would like to debug the issue to fix the code itself, if i have some time, so if you share the exact compiler installation you use, i'd give you some kudos Smile

Par theNestruo

Champion (324)

Portrait de theNestruo

06-08-2021, 16:23

Main problem is fopen(argv[1], "r")), that should be fopen(argv[1], "rb")) (please note the extra "b"). Otherwise, the .BAS file is open as a text file and getc() sometimes returns -1.

I have also #include <stdlib.h> and replaced short character; short forwarded by unsigned char character; unsigned char forwarded; within main (seems better than short for reading bytes).

Here is the modified source code: modified list.c (it also fixes minor warnings and has a slightly different indentation because I was struggling to read it; sorry).

It compiles with gcc -Wall -O3 list.c -o list.exe, and I'm using gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0.

Par Briqunullus

Champion (433)

Portrait de Briqunullus

06-08-2021, 17:15

theNestruo wrote:

Main problem is fopen(argv[1], "r")), that should be fopen(argv[1], "rb")) (please note the extra "b").

True! I just figured it out myself as well. I was examining the listings in a hex editor on the exact points of failure as I stumbled on 0x1a bytes on both of them. That was my eureka moment. Thanks for helping out though. Yeah, the code could do with a little cleanup. And I wonder if a MSX-DOS version exists.

Par Pencioner

Scribe (1480)

Portrait de Pencioner

06-08-2021, 19:39

Oh, yeah, i didn't have a look to code yet but you nailed it. On Linux and Unix "r" and "rb" will behave the same while in Windows it makes difference. Good catch and nice to see tool being patched Smile I think it should be easy enough to compile for MSX-DOS with SDCC and Fusion-C lib (or maybe change syntax to old ANSI C style and compile with some native compiler)

Par Briqunullus

Champion (433)

Portrait de Briqunullus

06-08-2021, 22:05

I found a few issues when I ran the tool. First, special MSX characters between quotes (e.g. PRINT "SPECIAL MSX CHARACTERS") get processed as if they were tokens. And secondly, a REM after a semicolon throws an error.

Maybe I'll fix those issues in a later stage. For now, it's not a problem for me. Because I only want to categorize a bunch of listings and often viewing the first couple of lines is enough. Big smile