Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi

[nil-admirari@mailo.com]

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-request@ffmpeg.org with subject "unsubscribe".