RTS may emit a localized heap profile that hp2ps can't read

Summary

RTS's output printf("%f") is incompatible with hp2ps's /[0-9.]*/ for some locales.

Steps to reproduce

Generate a heap profile after having invoked setlocale() with a locale that doesn't use a full stop '.' 0x2E as a decimal separator. For example "fr_FR".

I have a small test case at https://gitlab.haskell.org/jbm/ghc/-/tags/prof-locale-bug

Expected behavior

RTS output and hp2ps input ought to be compatible.

Discussion

There are more or less 3 ways of solving this.

1. accept them as potentially incompatible (status quo)
2. enforce POSIX on the generation side
3. allow all locales on the parsing side

I'm rather in favor of option 2, considering:

• the user is entitled to change the locale as they see fit, and we shouldn't prevent them from profiling a localized program. (for perspective, in my case, it was gi-glib who performed the setlocale() call)

• the parser on the hp2ps side is in pure Haskell, it's going to have a hard time accepting all possible locales as an input.

I have a candidate patch for that way of solving at https://gitlab.haskell.org/jbm/ghc/-/tags/prof-locale-patch

As mentioned above, I also have a demonstration test case, but I'm not sure how it could be made reproducible without requiring a specific locale to be deployed on every tester's environment.