Some of the CI tests fail with the latest sources on a Windows configuration about sjasmplus HOT 4 CLOSED

Oh, seems like my style of "text" .bin files backfired. The git is probably thinking they are text files, and during checkout adjusting LF to CRLF in those files, damaging them.

If you are using tools (text editor/compiler/...) which are capable to handle UNIX line-ends, I would suggest to reconfigure git for this project to checkout files without adjustments, but if you are editing sjasmplus sources or creating new asm files, then pushing back with unix LF only would be nice.

Can't currently think of some better solution, it's probably manageable with auto-conversion if you have in project only text/binary files where git heuristic works, but unfortunately the tests folder is full of "binary" files which may be mistaken for ASCII text. Or I can maybe mark .bin/.tap/*.raw as "binary" by .gitattributes file, but that will probably not resolve all of the errors. But I would prefer using LF, as I will eventually forget about it, and it will clash with some of my "great" ideas in future.. ;) :D

from sjasmplus.

That did the trick it seems, thanks. I'm still getting the same error for wrong_index_offset.asm though. Looking at the test contents, does it have to do with the Cyrillic locale? - I'm probably using that here (system language is Russian) if that makes a difference.

from sjasmplus.

$ hd wrong_index_offset.asm 
00000000  20 20 20 20 4c 44 20 20  41 2c 28 49 59 97 35 30  |    LD  A,(IY.50|
00000010  29 20 3b 20 63 6f 64 65  20 31 35 31 2c 20 6c 6f  |) ; code 151, lo|
00000020  6e 67 20 64 61 73 68 20  69 6e 20 43 79 72 69 6c  |ng dash in Cyril|
00000030  6c 69 63 20 63 70 31 32  35 31 0a 20 20 20 20 4c  |lic cp1251.    L|
00000040  44 20 20 41 2c 28 49 59  2d 35 30 29 0a           |D  A,(IY-50).|
0000004d

What does it contain on yours? (the important part is that 97 at first line, when I switch my editor to cp1251, I see long dash similar "-")

So it's either the ASM file is already modified on your system by who-knows-what-and-why (maybe pro-active editor? Or even git?), and in that case error is OK.

Or your ASM is same as original, but the sjasmplus does produce different result. Not sure why it would, can't recall if it has some autodetection of current system encoding and does something different then, but even then, it seems to me like on your machine the sjasmplus doesn't see anything between IY and 50, reading them as label id together IY50, which I can't explain even if some unexpected DOS 866 vs cp1251 encoding war would happen, I would expect still "something" in between.

from sjasmplus.

Maybe it's reading source as text file, and windows file API may do something with the byte stream, so the file on disk is identical, but the sjasmplus does process different data? But I can't imagine why precisely only 0x97 would get damaged, in OS with Cyrillic locale, that still doesn't make much sense to me, I would rather expect that from my linux box where 0x97 in that context is invalid utf-8 char-code (when opened as utf-8 encoded file). So it's probably something in sjasmplus, I just can't recall what it may be....

...so far mystery, if you want to spend your time on this, try to find out at which stage and how the char is lost (but I think this is low priority).

from sjasmplus.