> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of nil-
> admir...@mailo.com
> Sent: Thursday, May 5, 2022 10:20 PM
> To: ffmpeg-devel@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
_______________________________________________
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".
