> 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-requ...@ffmpeg.org with subject "unsubscribe".
