[Security] Deterministic Memory Leak and Dangling Pointer in SQLParser::tokenize #261

Clear and concise description of the bug:
A deterministic memory leak and a dangling pointer vulnerability exist in the hsql::SQLParser::tokenize function. During the tokenization loop, the dynamic memory (sval) allocated for the first token is overwritten by a subsequent hsql_lex call before it can be freed, resulting in a permanent leak. Furthermore, the pointer is not set to nullptr after calling free(yylval.sval), allowing an invalid memory address to be passed into subsequent iterations, which creates a high risk of memory corruption.

Steps to reproduce the bug :
1.Modify src/SQLParser.cpp by adding debug print statements around the free(yylval.sval) call within the tokenize function to observe the pointer state:

if (token == SQL_IDENTIFIER || token == SQL_STRING) {
    std::cout << "[DEBUG] Found String/ID, address in yylval.sval: " << (void*)yylval.sval << std::endl;
    free(yylval.sval);
    std::cout << "[DEBUG] After free, pointer is now dangling: " << (void*)yylval.sval << std::endl;
}

2.Create a Proof of Concept (PoC) file named poc.cpp with an input string containing multiple consecutive identifiers:

#include "SQLParser.h"
#include <vector>
#include <string>
int main() {
    std::string sql = "\"string_one\" \"string_two\" \"string_three\"";
    std::vector<int16_t> tokens;
    hsql::SQLParser::tokenize(sql, &tokens);
    return 0;
}

3.Compile the PoC with AddressSanitizer (ASan) enabled:

g++ -g -fsanitize=address -I./src $(find ./src -name "*.cpp") poc.cpp -o poc

4.Execute the compiled binary:

./poc

Expected behavior:
The program should correctly track and release all dynamically allocated memory for tokens. After a free() operation, the pointer should be explicitly nullified to prevent the use of invalid addresses in subsequent logic.

Observed behavior:
1.Memory Leak: LeakSanitizer (LSan) detects a leak originating from the very first hsql_lex call at the start of the tokenize function, as that specific pointer is lost when the loop starts.
2.Dangling Pointer: Debug logs show that the pointer variable retains the exact same hexadecimal address after the free operation (e.g., 0x602000000070), confirming it is in a dangling state.

Platform(s) (compiler version, operating system version, CPU) on which the bug was observed:
OS: Ubuntu Linux (20.04).
Compiler: g++ with AddressSanitizer support.
CPU: x86_64.

sql-parser release(s), commit(s), or branch(es) in which the bug was observed:
Observed in the latest version of the main branch.