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

[Tobias Rapp <t.rapp@noa-archive.com>]

On 11/05/2022 01:32, Soft Works wrote:
>>
>> [...]
>>
>> The prefixing can be implemented as a function and then be used
>> in file_open.c.
>>
>> Other file system related functions like mkdir, rename, rmdir, etc.
>> are already intercepted in os_support.h, and the prefixing can be
>> applied there.
>>
>> Maybe I missed some cases, I have not fully analyzed the situation,
>> but surely there are just a small number of places that need to
>> be changed and not 587.
>>
>>
>> For the procedure of prefixing I would take a look at how it's done
>> in .NET. This is probably the most mature code for handling this
>> and might save us from dealing with issues and regressions until we
>> got it right.
> 
> The logic they use is here:
> 
> https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs
> 
> Probably it can be simplified a bit.

Out of curiosity I searched for some automatic path prefixing code and 
the author of this file claims that it should be handling most corner cases:

https://github.com/JFLarvoire/SysToolsLib/blob/master/C/MsvcLibX/src/mb2wpath.c

That amount of logic inside CorrectWidePath() does not look appealing to 
me. And even if we simplify that now I guess it will grow once the 
corner cases drop in via bug reports.

So I'm in favor of removing the MAX_PATH limit, converting needed Win32 
function calls from ANSI to WideChar, and adding the longPathAware 
manifest flag. I think the activeCodePage=UTF-8 patch could break 
Windows applications that expect the system-wide ANSI codepage to be 
used for FFmpeg text output, though.

Regards,
Tobias

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