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

[nil-admirari at mailo.com]

> You normally don't load libraries from such longs paths.

And? 80% of FFmpeg functionality is normally not used.

> But file IO is a fundamental feature where a common and predictable 
> behavior is crucial.

You're talking as if the manifest change somehow broke or fundamentally altered
file IO, which it clearly did not.

> That's true, but the file IO in ffmpeg does not use MAX_PATH buffers,
> so it's only about those few specific cases:

I'm glad it doesn't use MAX_PATH everywhere. Takes only 6 pathes to fix,
not a thousand.

> Patch 2/6: Removing the fixed-size buffer is surely a good change,
> but can't you just completely remove the charset 
> conversion and use the same file IO patterns that ffmpeg
> is using everywhere else?

If you were to look at the code, you would've seen that charset conversion
was already there. AviSynth is not Unicode-aware, it expects ANSI strings.
Inline charset conversion was replaced by a library call, which, again,
was already there, only slightly extended.

> Patch 4/6: Seems to be pointless because you cannot run ffmpeg.exe from
> a long path anyway. Neither with cmd nor with powershell.
> Even if you could, it would be a pretty exotic use case.

This current limitation may disappear in a future version of Windows,
the same way path limit disappeared.

> And the servers?

Servers have the same lifecycle as client versions do.

> And all those which are still using older versions?

For them manifest change is a no-op.

> Yes it is. Especially when you don't know that it's needed or whether
> it's needed or when it is needed.
> Also it requires administrative permissions which not everybody has.
> Further it's a serious change to OS behavior and you cannot expect that 
> all users are educated enough for being able to make this decision 
> and be confident that it won't have any unexpected side effects.

What does all of that have to do with these patches?

> That's what I tried to explain. "Any other patch" makes a change
> after which you know that the change has been made.
>
> But adding those attributes will impose changes that will be effective
> under certain conditions only and about which neither the user nor the
> application "knows" whether they are effective or not.

Before these patches FFmpeg cannot handle long paths. After these patches, it can.
They are certainly not invisible.

> No. There's are common file APIs where such change could be made.

During the review of these patches it was found that parts FFmpeg use av_fopen_utf8,
while others use plain fopen. There is no common file API.

> PS: Your line breaks were all doubled. Please check before replying.

Were normal in email client. I don't know how they got garbled. My previous messages
didn't have such a problem.