Mostly inconsequential leak

[guregu]

Here is a weird one, if you catch then fail a parens parse error it will leak some of the partial parsing results:

?- catch(read_term_from_chars("hello(", T, []), Err, fail).

Not a pressing issue for me but I figured I'd report it.

$ valgrind --leak-check=full ./tpl
==33110== Memcheck, a memory error detector
==33110== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==33110== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==33110== Command: ./tpl
==33110== 
?- catch(read_term_from_chars("hello(", T, []), Err, fail).
   false.
?- halt.
==33110== 
==33110== HEAP SUMMARY:
==33110==     in use at exit: 236,303 bytes in 238 blocks
==33110==   total heap usage: 14,364 allocs, 14,126 frees, 82,890,793 bytes allocated
==33110== 
==33110== 23 bytes in 1 blocks are definitely lost in loss record 14 of 78
==33110==    at 0x48850E8: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==33110==    by 0x24C6E7: make_string_internal (parser.c:122)
==33110==    by 0x2638DF: tokenize (parser.c:4087)
==33110==    by 0x260D83: tokenize (parser.c:3646)
==33110==    by 0x260D83: tokenize (parser.c:3646)
==33110==    by 0x263F57: run (parser.c:4125)
==33110==    by 0x280D2B: pl_eval (prolog.c:148)
==33110==    by 0x11901F: main (tpl.c:378)
==33110== 
==33110== LEAK SUMMARY:
==33110==    definitely lost: 23 bytes in 1 blocks
==33110==    indirectly lost: 0 bytes in 0 blocks
==33110==      possibly lost: 0 bytes in 0 blocks
==33110==    still reachable: 236,280 bytes in 237 blocks
==33110==         suppressed: 0 bytes in 0 blocks
==33110== Reachable blocks (those to which a pointer was found) are not shown.
==33110== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==33110== 
==33110== For lists of detected and suppressed errors, rerun with: -s
==33110== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)