L’ANALISI
llama.cpp b12199: tool call e byte UTF-8 non validi
llama.cpp b12199 sanitizza UTF-8 non valido in quattro percorsi del parser PEG delle tool call. È una prerelease, senza test locali riprodotti.

In breve: llama.cpp b12199 sostituisce letture del testo grezzo con sanitized_text() in quattro percorsi delle tool call. Serve a evitare che sequenze UTF-8 non valide arrivino alla serializzazione JSON e provochino l'eccezione descritta nella pull request. Non dimostra che l'agente scelga strumenti o argomenti corretti. llama.cpp b12199: prerelease ufficiale.
Analisi documentale delle API ufficiali GitHub e del diff della pull request 31861. Merge dell'8 novembre alle 05:06:16 e prerelease alle 05:43:58, ora italiana. Le due date descrivono lo stesso aggiornamento. Nessuna build, prova end-to-end o misura di prestazioni è stata eseguita in questo ciclo.
Che cosa cambia nel parser delle tool call?
Il diff modifica common/chat-peg-parser.cpp in quattro punti: identificatore dello strumento, contenuto degli argomenti e conversioni delle stringhe nei percorsi Gemma4 e MiniMax-M3. Il testo viene sanitizzato prima della successiva gestione JSON. Il perimetro è quello del parser PEG: non è corretto estendere automaticamente la correzione a ogni formato di chat, backend o applicazione che incorpora llama.cpp.
Diff ufficiale: i quattro percorsi modificati.
Quale errore descrive la pull request?
Il contributore segnala type_error.316 quando una tool call contiene UTF-8 non valido. Spiega che ragionamento e contenuto disponevano già della sanitizzazione, mentre alcuni percorsi degli strumenti leggevano node.text. La modifica allinea quei percorsi alla gestione già presente. Questo descrive una causa documentata dell'eccezione, non la frequenza con cui si presenta nei flussi reali.
Pull request 31861: sanitizzazione UTF-8 nelle tool call.
Che cosa provano i test e che cosa manca?
La descrizione della pull request riporta 44 test e 225 asserzioni senza errori, attribuiti al contributore. Il diff restituito dall'API durante questa verifica mostra soltanto il file del parser: non contiene modifiche ai test. I risultati restano quindi dichiarazioni del progetto, non una riproduzione indipendente. Una verifica locale dovrebbe confrontare la stessa richiesta prima e dopo il commit, conservando input e output.
Pull request 31861: sanitizzazione UTF-8 nelle tool call · Diff ufficiale: i quattro percorsi modificati.
Quando vale la pena preparare un aggiornamento?
Il controllo è pertinente se un'integrazione usa il parser interessato e incontra errori di codifica negli argomenti degli strumenti. Prima di sostituire un runtime funzionante, fissare versione, template di chat e caso di errore. Provare in un ambiente isolato anche una richiesta valida: eliminare un'eccezione non deve nascondere argomenti alterati. La release è marcata prerelease nel repository; la sua presenza non è una certificazione di stabilità.
llama.cpp b12199: prerelease ufficiale · Diff ufficiale: i quattro percorsi modificati.
Condizioni e limitazioni
Lettura della prerelease, della pull request e del diff al merge 372dc5ca157276beb6c67b2e92477e8d662e964a. Nessuna compilazione o inferenza eseguita qui. I test dichiarati dal contributore non sono stati riprodotti; il diff acquisito contiene un solo file del parser. Nessuna classificazione CVE o gravità di sicurezza attribuita.
Checklist pratica
- Annotare commit, backend, modello e template della build attuale.
- Conservare una copia del runtime precedente e un piano di ritorno.
- Riprodurre il caso con dati sintetici, senza eseguire strumenti con effetti reali.
- Confrontare errore, JSON risultante e argomenti prima e dopo il fix.
- Verificare che le richieste UTF-8 valide mantengano il comportamento atteso.
- Separare i risultati misurati localmente da quelli dichiarati nella pull request.