On Sep 12 01:05, Takashi Yano via Cygwin-patches wrote: > On Fri, 11 Sep 2020 16:06:01 +0200 > Corinna Vinschen wrote: > > On Sep 11 21:35, Takashi Yano via Cygwin-patches wrote: > > > What do you mean by "just drop any handling"? > > > > > > Do you mean remove following if block? > > > > > + if (cp_from == CP_UTF7 || IS_ISO_2022 (cp_from) || IS_ISCII > > > > > (cp_from)) > > > > > + /* - MB_ERR_INVALID_CHARS does not work properly for UTF-7. > > > > > + - ISO-2022 is too complicated to handle correctly. > > > > > + - FIXME: Not sure what to do for ISCII. > > > > > Therefore, just convert string without checking */ > > > > > wlen = MultiByteToWideChar (cp_from, 0, ptr_from, len_from, > > > > > wbuf, NT_MAX_PATH); > > > In this case, the conversion for ISO-2022, ISCII and UTF-7 will > > > not be done correctly. > > > > > > Or skip charset conversion if the codepage is EBCDIC, ISO-2022 > > > or ISCII? What should we do for UTF-7? > > > > Nothing, just like for any other of these weird charsets. Cygwin never > > supported any charset which wasn't at least ASCII compatible in the > > 0 <= x <= 127 range. Just ignore them and the possibility that a > > user chooses them for fun. > > > > > What should happen if user or apps chage codepage to one of them? > > > > Garbage output, I guess. We shouldn't really care. > > Do you mean a patch attached?
Yes. I pushed it. We should really not care for them. Thanks, Corinna
