You have completely ignored my question, haven't you? Here it is again: >> Is there a Path struct, analogous to LLVM class, that all of FFmpeg is using? >> Or FFmpeg isn't using any special structs and paths are indistinguishable >> from ordinary strings?
> Read again. As each lib gets its own copy of file_open.c there's > no problem using av_fopen_utf8. The concern in that message was > about it being a public API that could be used by external callers. av_fopen_utf8 wasn't mentioned because it has a particular problem. It was mentioned to say that >> FFmpeg sometimes uses av_fopen_utf8 and sometimes just plain fopen i.e. there is no standardised path handling. > That's the pending issue with your 4/6 which is probably ok otherwise. It's not an issue with my patch. It's something that was already there, and is retained not to break something. > 3/6 is pointless without 5/6 It is pointless in one and only one case: no long path support arrives ever. Please reread: > MAX_PATH-sized buffers simply do not work with long paths, even the ones > that start with \\?\. You will still have to replace them with dynamically > allocated buffers. And that's what the majority of this patch-set > is about, not about the manifest. > 2/6 is pointless without 6/6 Wrong. 6/6 enables process-wide UTF-8. utf8toansi allocates buffers of necessary size instead of using MAX_PATH. utf8toansi doesn't care whether ansi is UTF-8 or a legacy encoding. > 1/6 remaining bits can be inlined in 4/6 Why should they? Are two calls to WideCharToMultiByte + allocation more readable than a single call to wchartoansi? _______________________________________________ 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".
