Re: [FFmpeg-devel] [PATCH 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

[nil-admirari@mailo.com]

> The functions are needed in both. file_open.c cannot be included
> in libavformat/os_support.h and neither the other way round, 
> so they need to be in a 3rd place. How about renaming
> wchar_filename.h to windows_filename.h ?

Probably it's better to rename.

> I have skipped those checks because we won't have partially qualified
> paths at this point (due to having called GetFullPathNameW) and
> device paths are not allowed to be longer than 260, so this it might
> happen that the UNC prefix gets added, but only when it's a long
> path which doesn't work anyway (I've tested those cases).

I think it's better to test for \\.\ explicitly in path_is_extended:
1. It's not obvious that \\.\ aren't allowed to be long.
2. Probably FFmpeg is not going to have a longPathAware manifest,
   but it can be linked with an EXE with such a manifest.
   Would MAX_PATH restriction still apply?

You have the checks inside of get_extended_win32_path and none
inside of add_extended_prefix. Yet add_extended_prefix can be called
by anyone: it's not private. Thus add_extended_prefix either should be inlined,
or it should have the necessary checks in place. Otherwise you end up with
an API that's easy to use incorrectly and hard to use correctly, and it should be
the other way around.



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