renum 6.1.0 silently fails if nfo file contains an action B

[PikkaBird]

Using 6.1.0 on Win 10, renum silently fails (does not update/resave the file) if the nfo contains an action B.

I discovered this with a custom action B, and verified it in multiple different nfo files with the example code from the wiki, which is:

2 * 6  07 85 01 01 37 01

3 * 17 0B 03 7F 02 "newtrains on" 00

If I simply change the "0b" to "0c", renum processes the file successfully. If it is then changed back to 0b and the grf compiled, the action B works as expected.

[rubidium42]

0 * 4 00 00 00 00
-1 * 6  07 85 01 01 37 01
-1 * 17 0B 03 7F 02 "newtrains on" 00
-1 * 6  0C "gibberish"

with nforenum -k <filename> becomes:

// Automatically generated by GRFCODEC. Do not modify!
// (Info version 5)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
    0 * 4	 03 00 00 00
    1 * 6	 07 85 01 01 37 01
    2 * 17	 0B 03 7F 02 "newtrains on" 00
    3 * 10	 0C "gibberish"

That seems to be doing what it's supposed to be doing on Linux, at least with the small example you posted.

The snippet you posted was not complete enough for nforenum to process the file for me. Can you provide a nfo file that shows the behaviour?

[PikkaBird]

The 4-line example you posted shows the behaviour on my system.

Note the lack of 'processing complete' after the first command. A blank .new file was created.
I then changed the 0b in sprite 2 to 0c and saved the file, and renum ran correctly.

[rubidium42]

Okay, then on Linux with my compiler I can't reproduce this. Neither with 6.1.0 nor with current master. I have tried the usual valgrind and undefined behaviour things, but could not find anything.

Sadly, I can't be of any further help as I don't have a Windows environment.