>> I'm wondering why it converts wchar back to ansi instead of utf8 in 4/4 and >> whether it won't fail then, when a path contains non-ANSI chars. > > Yes, that's a preexisting problem there. That patch gets rid of the fixed > path lengths without touching the rest of the charset handling there. > > There's paths from two sources; getenv() and from GetModuleFileName(). > These are passed to plain fopen() (which uses ANSI filenames). > > To make it entirely unicode compliant, we'd need to replace getenv() with > a wrapper that uses _wgetenv() and converts that to utf8, then convert the > GetModuleFileName() output to utf8 too, and switch the fopen() to > fopen_utf8.
Actually utf8toansi() was created for AviSynth, which doesn't have a Unicode API. getenv() and plain fopen() are used in cmdutils.c, which is the only file that haven't transitioned to avpriv_fopen_utf8() yet, but utf8toansi() is not used in cmdutils.c. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
