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

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of nil-
> admirari at mailo.com
> Sent: Saturday, May 7, 2022 7:33 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi
> 
> 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?

Paths are 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.

It needs to be found out why it was added to decide in which way it
can be adjusted.
 

> > 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.

I am sorry about that one. I was under the impression that it would
make sense only when forcing UTF8 code page for the whole application
via manifest.
I have no objections about it then, of course.

Kind regards,
softworkz