Hello Robert. I fear we might be at cross-purposes here ...
> On 22 Mar 2025, at 02:34, Robert Dubner <rdub...@symas.com> wrote: > > I can't comment on what happens on Apple systems. I've never tried it. > > I chose CP1252 because it seemed to have the greatest coverage for much of > western Europe. It also has very close to a one-to-one correspondence > with the EBCDIC CP1140. > > At the present time I personally am not prepared to go chasing down the > implications of switching away from CP1252 on the systems that I have > been, and continue to, focus on: X86_64 and aarch64. That is not what is being asked - at least not by me. I have found an issue with the current implementation on x86_64 (darwin), I’ve debugged it and found that it is the result of appending “//“ to “tocode” in iconv_open(). You might argue that this is a bug in the OS implementation - but: 1. that is outside my power to fix 2. from the man page (e.g. https://man7.org/linux/man-pages/man3/iconv_open.3.html) is its not evident that “tocode//“ is supported even on Linux. The description clearly says "When the string "//TRANSLIT" is appended to tocode,” and "When the string "//IGNORE" is appended to tocode" So I have proposed a fix that did not alter the behaviour for any other platform than Darwin/macOS, (which made use of an ISO spelling for 1252) you said you preferred to keep using CP1252. I responded with an amendment that keeps CP1252 everywhere but removes the trailing “//“ for Darwin/macOS. ** I am not expecting you to test on Darwin/macOS, I realise you might not have access, but I am asking you for approval (or rejection) of the patch that fixes this issue on the platform I maintain. thanks, Iain
