Fix locale-dependent float printing in GGUF metadata

[ssam18]

I was running some llama.cpp examples on a system with a German locale (de_DE) and noticed something odd - when llama-cli printed out the model metadata, all the float values had commas as decimal separators (like "0,000000") instead of periods. But when I ran llama-perplexity on the same model, it used periods normally.

After some digging, I found the issue was in the gguf_data_to_str() function in llama-impl.cpp. It was using std::to_string() to format floats, which respects the system's LC_NUMERIC locale setting. So depending on which tool you used and what locale it was running with, you'd get different formatting.

I've changed it to use std::ostringstream with std::locale::classic() instead, which always formats floats with a period as the decimal separator, regardless of the system locale. This should make the output consistent across all tools and locales.

Fixes #10613

[ssam18]

This was a fun one to track down! The locale dependency was subtle enough that most people probably wouldn't notice it unless they happened to be running with a non-English locale. I'm glad I could spot the inconsistency and fix it.

[SamareshSingh]

@ggerganov Please let me know if you need further help to finish this PR?

[ggerganov]

@JohannesGaessler Can you confirm it fixes #10613?

[JohannesGaessler]

This makes the prints in llama_model_loader consistent. However, these are not the only instances of inconsistent prints. If you scroll further down you'll see that essentially all floating-point prints are inconsistent. I think it would be preferable to use consistent locale settings for the llama.cpp binaries than to try and squash every single instance of std::to_string in the llama.cpp codebase.

[JohannesGaessler]

Originally all binaries were in the examples folder but nowadays there are also binaries in the tools folder (which I assume you overlooked?).

[ssam18]

Originally all binaries were in the examples folder but nowadays there are also binaries in the tools folder (which I assume you overlooked?).

yeah, just now I fixed it.

[ngxson]

I'm wondering if there is any tricks to avoid adding this to every example. It adds a bit of boilerplate everywhere IMO.

Since most examples initialize common_params right at the beginning of main(), can we put this inside the constructor of common_params instead?

[SamareshSingh]

I'm wondering if there is any tricks to avoid adding this to every example. It adds a bit of boilerplate everywhere IMO.

Since most examples initialize common_params right at the beginning of main(), can we put this inside the constructor of common_params instead?

Yes, this is a good idea to put this inside the constructor. I am working on this

[ngxson]

Ah sorry, common_params_parse should be the better place. common_params doesn't have a constructor

[JohannesGaessler]

I don't think we use common_params in every example/tool though. And my opinion is that a library should not be changing global locale settings upon use, that should only be done in the main function.

[ngxson]

@JohannesGaessler for all examples don't use it, we can set it explicitly on main.

I think doing it in common_params_parse does make sense though, as the libcommon also have various code paths to setup the CLI environment, including logging system, console, etc. So adding this as a "formatting setup" does make sense IMO

[JohannesGaessler]

I don't see us changing global settings anywhere in common_params_parse. That is fundamentally not something that a library should be doing upon use unless it is done by an explicit and dedicated function.

[ngxson]

Technically the global settings are set by common_init(), but I agree that it's only settings bound to the application, not system settings like locale.

I'm ok with both approaches (either explicitly set on main() or libcommon), but if you don't prefer to add it to libcommon then no problem, @ssam18 I think you will need to revert the last commit

[ssam18]

What are we waiting on for this PR? Did I miss something?

[JohannesGaessler]

Sorry, IIRC there were CI failures where I wasn't sure whether they were being caused by this PR. I meant to look into it again and then forgot.

[ssam18]

I want to followup for this PR. please get it reviewed.

[JohannesGaessler]

In that case, please rebase on top of master, resolve the merge conflicts, and ensure that there are no CI failures.

[ssam18]

I am not sure the failure we are seeing is related to this change.

[JohannesGaessler]

Yes, the CI failures seem to be unrelated.