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

Soft Works softworkz at hotmail.com
Fri May 6 01:38:40 EEST 2022



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of nil-
> admirari at mailo.com
> Sent: Thursday, May 5, 2022 10:20 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
> libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
> utf8toansi


[..]

> As a matter of fact, you are. Your alternative method implies
> ploughing
> through hundreds of C files normalising path handling across the
> entire application,

Almost everybody here knows that this isn't true.


> And even then I have some bad news for you. 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

Why should that be bad news for me?

Those are three very specific cases and we had already covered this.
I had also said that it surely makes sense to eliminate fixed size buffers.

But that's all just distraction from the main subject, which is 
"Long Path Support in ffmpeg on Windows".

My point is very simple: It should be a solution that will always 
work and not just sometimes.

I stripped the remaining points because this is just going in circles.
My opinion should be sufficiently explained by now, and I'd like to 
leave room for other opinions.

Kind regards,
softworkz





More information about the ffmpeg-devel mailing list