Hi Ingo, On Mon, Feb 3, 2020 at 6:31 AM Ingo Schwarze <[email protected]> wrote: > The function locale_charset() appears to be part of the converters/libiconv > package, but it appears to be totally undocumented. I failed to > find any documentation whatsoever: neither in the package nor even > with Google on the web. While iconv(3) is in POSIX, locale_charset() > is not. I think we should avoid using stuff when it is unclear > what it is, so consider forcing HAVE_LIBCHARSET to undefined in the > port (i'm not saying you must do this, only that it could be > considered).
Done in my patch. > And indeed, UTF-8 is the only non-POSIX charset that OpenBSD supports, > and there are no plans to support any others in the future. Seems to be working as advertised. > Consequently, nl_langinfo(CODESET) will always return either "US-ASCII" > or "UTF-8" on OpenBSD. Yes, as prominently documented in the man pages :) > Three apsects of the patch look bogus in particular: > > 1. Avoiding nl_langinfo(3). > There is no longer anything wrong with that function. Confirmed. > 2. Inspecting HS_ENCODING. > It appears the code wants to inspect the current locale. > If any environment variable, then LC_ALL/LC_CTYPE/LANG > should probably be inspected, not HS_ENCODING. > The code in the patch gives me the impression that this is > probably already done with setlocale(3) elsewehere in the > program, so i'm not sure the environment should be inspected > again. Yes, setlocale is one of the first thing done by GHC runtime. https://github.com/ghc/ghc/blob/7f72b540288bbdb32a6750dd64b9d366501ed10c/rts/RtsStartup.c#L156 > Right, and you might also try convincing ./configure (or whatever is > used in the build system) to switch HAVE_LIBCHARSET off, unless that > has unrelated detrimental effects. Thanks for the tip! Done. Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
