You're correct: I didn't understand what was going on. I still don't.
As a matter of fact: Although the relevant code in charmaps.cc is my coding style, I frankly don't recognize it. I remember doing that conversion with my own tables and routines at one point, but apparently I decided, or was convinced, that doing UTF-8 to eight-bit character set conversions was best done through iconv. I just don't remember. But, by all means, if you have a fix for something I am not seeing, a fix that doesn't mess with the status quo ante, then by all means, apply it. I regret any confusion. Bob D. > -----Original Message----- > From: Iain Sandoe <i...@sandoe.co.uk> > Sent: Saturday, March 22, 2025 04:29 > To: Robert Dubner <rdub...@symas.com> > Cc: GCC Patches <gcc-patches@gcc.gnu.org> > Subject: Re: [PATCH] cobol: Address some iconv issues. > > 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
