amata_next_string() doesn't look like it's handling 0x07 as a terminator

[tstack]

I think this chunk of code allows a string terminator of ST or BEL:

notcurses/src/lib/automaton.c

Lines 560 to 563 in 3a3c75e

	if(candidate == 0x1b || candidate == 0x07){
	a->state = e->trie[candidate];
	a->instring = 0;
	}

However, the amata_next_string() only looks for the escape:

notcurses/src/lib/in.c

Lines 446 to 452 in 3a3c75e

	// same deal as amata_next_numeric, but returns a heap-allocated string.
	// strings always end with ST ("x1b\\"). this one *does* return NULL on
	// either a match failure or an alloc failure.
	static char*
	amata_next_string(automaton* amata, const char* prefix){
	return amata_next_kleene(amata, prefix, '\x1b');
	}

I think things usually work because there is another escape sequence following the one currently being processed. So, amata_next_kleene() skips over the BEL and hits the escape in the next sequence. However, if something like a palette response comes at the very end of the buffer, amata_next_kleene() will run past the end of the buffer. Here are some of the debug logs with an ASAN backtrace when this happened on a run:

2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_melange:2381:input 988 (0)/26 [0x1b] ( )
process_escape:2227:walk result on 93 (]): 0 431
process_escape:2227:walk result on 52 (4): 0 451
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 59 (;): 0 452
process_escape:2227:walk result on 56 (8): 0 453
process_escape:2227:walk result on 56 (8): 0 453
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 59 (;): 0 454
process_escape:2227:walk result on 114 (r): 0 455
process_escape:2227:walk result on 103 (g): 0 456
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 98 (b): 0 457
process_escape:2227:walk result on 58 (:): 0 458
process_escape:2227:walk result on 56 (8): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 55 (7): 0 459
process_escape:2227:walk result on 56 (8): 0 459
process_escape:2227:walk result on 55 (7): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 47 (/): 0 459
process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 48 (0): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 47 (/): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 48 (0): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 48 (0): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 =================================================================
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 ==96908==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61e00006e238 at pc 0x0001080feb64 bp 0x00016b5da110 sp 0x00016b5da108
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 READ of size 1 at 0x61e00006e238 thread T5
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674     #0 0x1080feb60 in amata_next_kleene in.c:400
    #1 0x1080fed9c in amata_next_string in.c:452
    #2 0x1080f96f0 in palette_cb in.c:1486
    #3 0x1080c2f44 in walk_automaton automaton.c:569
    #4 0x1080ec748 in process_escape in.c:2225
    #5 0x1080e5654 in process_melange in.c:2384
    #6 0x1080f13f4 in process_ibuf in.c:2438
    #7 0x1080e7afc in input_thread in.c:2648
    #8 0x10eda1858 in asan_thread_start(void*)+0x40 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x51858)
    #9 0x19346b2e0 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x72e0)
    #10 0x1934660f8 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x20f8)
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 0x61e00006e238 is located 0 bytes after 2488-byte region [0x61e00006d880,0x61e00006e238)
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 allocated by thread T0 here:
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674     #0 0x10eda4c04 in malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54c04)
    #1 0x1080e60e0 in create_inputctx in.c:1939
    #2 0x1080e5e64 in init_inputlayer in.c:2656
    #3 0x10819e688 in interrogate_terminfo termdesc.c:1383
    #4 0x10812e37c in notcurses_core_init notcurses.c:1350
    #5 0x1074112c4 in screen_curses::create(notcurses_options const&) view_curses.cc:1295
    #6 0x104c3e364 in looper() lnav.cc:1230
    #7 0x104c18794 in main lnav.cc:3699
    #8 0x1930e8270  (<unknown module>)

(There's some extra crud from my own logging. Note that the notcurses line numbers won't line up with top-of-tree since I've made some changes)