Bruno Haible <[EMAIL PROTECTED]> writes: > In approach (2) LIBDIR will be an UTF-8 encoded pathname. The ISSLASH > operation will therefore work correctly. However, fopen() expects a > string in locale encoding, not in UTF-8 encoding. Therefore we have > to replace the last line with
OK, I'm starting to see the problem. Yes, obviously that is going to be a pain. I agree with you that file names should just use one encoding. If the user wants an UTF-8 world, the user should specify all the file names components in UTF-8, and then everything will work. If the user wants an EUC-JP world (not doable in Windows apparently, but the tradition for Japanese Solaris) then all the file names should be specified in EUC-JP. The application shouldn't have to convert back and forth internally: it should stick to just one encoding, and let the wrapper functions (if any) deal with it. So if I understand you correctly, yes, I'd favor (4) for gnulib code; gnulib code shouldn't have to convert file-name pieces into a common encoding. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
