From: Soft Works <softworkz@hotmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/os_support: Support long file names on Windows Date: Sun, 15 May 2022 22:14:54 +0000 Message-ID: <DM8P223MB03654CA8C7AF59E21C20F976BACC9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw) In-Reply-To: <ea-mime-628150cc-5a26-215eeed5@www-7.mailo.com> > -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of nil- > admirari@mailo.com > Sent: Sunday, May 15, 2022 9:13 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/os_support: Support > long file names on Windows > > > diff --git a/libavformat/os_support.h b/libavformat/os_support.h > > In addition to what you've already added, this file defines stat as: > > #ifdef _WIN32 > ... > # ifdef stat > # undef stat > # endif > # define stat _stati64 > ... > > which is > 1. not wide-char aware (_wstati64 does exist) > 2. not long path aware. That's a good point, even though plain stat is used in 2 cases only. We already have win32_stat, but what's a bit tricky is that the struct that this function takes as a parameter is named the same as the function itself. Now I have repeated the definition of 'struct stat' as 'struct win32_stat', but maybe someone can come up with a better way. Would you have any idea perhaps? > Also there is a function: > > static inline int is_dos_path(const char *path) > { > #if HAVE_DOS_PATHS > if (path[0] && path[1] == ':') > return 1; > #endif > return 0; > } > > Now, DOS paths C:... end up being \\?\C:.... Are you sure it won't > break something down the line? The prefixing of paths is always done right before calling any of the Windows APIs. Original strings are never modified like this. You can be sure, because all those operations are done on WCHAR strings only. You could ask the question only about the case where a user might supply a path that is prefixed already, but when we look at the only(!) usage of this function then it is about handling URL and checking URL paths and a path starting with \\?\ wouldn't be valid in a URL anyway. So I don't think that this is of any concern, but it was a good point to verify this. Thanks for the review! 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-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2022-05-15 22:15 UTC|newest] Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-13 9:53 [FFmpeg-devel] [PATCH 0/2] " ffmpegagent 2022-05-13 9:53 ` [FFmpeg-devel] [PATCH 1/2] avutil/wchar_filename, file_open: " softworkz 2022-05-15 19:02 ` nil-admirari 2022-05-15 20:24 ` Soft Works 2022-05-16 8:34 ` nil-admirari 2022-05-13 9:53 ` [FFmpeg-devel] [PATCH 2/2] avformat/os_support: " softworkz 2022-05-15 19:13 ` nil-admirari 2022-05-15 22:14 ` Soft Works [this message] 2022-05-16 8:19 ` nil-admirari 2022-05-13 10:02 ` [FFmpeg-devel] [PATCH 0/2] " Soft Works 2022-05-15 19:36 ` nil-admirari 2022-05-15 20:31 ` Soft Works 2022-05-16 8:45 ` nil-admirari 2022-05-17 0:37 ` Soft Works 2022-05-15 22:17 ` [FFmpeg-devel] [PATCH v2 " ffmpegagent 2022-05-15 22:17 ` [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename, file_open: " softworkz 2022-05-16 8:12 ` nil-admirari 2022-05-16 21:14 ` Soft Works 2022-05-17 15:06 ` nil-admirari 2022-05-17 15:28 ` Soft Works 2022-05-17 15:43 ` Soft Works 2022-05-20 17:51 ` nil-admirari 2022-05-20 18:03 ` Soft Works 2022-05-21 11:08 ` nil-admirari 2022-05-21 11:12 ` Soft Works 2022-05-23 15:35 ` nil-admirari 2022-05-23 15:47 ` Soft Works 2022-05-23 17:12 ` Hendrik Leppkes 2022-05-24 5:32 ` Soft Works 2022-05-24 5:54 ` Soft Works 2022-05-24 9:47 ` Soft Works 2022-05-24 12:11 ` nil-admirari 2022-05-15 22:17 ` [FFmpeg-devel] [PATCH v2 2/2] avformat/os_support: " softworkz 2022-05-16 21:23 ` [FFmpeg-devel] [PATCH v3 0/2] " ffmpegagent 2022-05-16 21:23 ` [FFmpeg-devel] [PATCH v3 1/2] avutil/wchar_filename, file_open: " softworkz 2022-05-16 21:23 ` [FFmpeg-devel] [PATCH v3 2/2] avformat/os_support: " softworkz 2022-05-23 11:29 ` [FFmpeg-devel] [PATCH v4 0/2] " ffmpegagent 2022-05-23 11:29 ` [FFmpeg-devel] [PATCH v4 1/2] avutil/wchar_filename, file_open: " softworkz 2022-05-23 11:29 ` [FFmpeg-devel] [PATCH v4 2/2] avformat/os_support: " softworkz 2022-05-24 8:43 ` [FFmpeg-devel] [PATCH v5 0/2] " ffmpegagent 2022-05-24 8:43 ` [FFmpeg-devel] [PATCH v5 1/2] avutil/wchar_filename, file_open: " softworkz 2022-05-24 9:09 ` Martin Storsjö 2022-05-24 8:43 ` [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: " softworkz 2022-05-24 9:23 ` Martin Storsjö 2022-05-24 9:33 ` Soft Works 2022-05-24 10:25 ` Martin Storsjö 2022-05-24 11:15 ` Soft Works 2022-05-24 11:26 ` Martin Storsjö 2022-05-24 12:31 ` Soft Works 2022-05-24 12:44 ` Martin Storsjö 2022-05-24 13:41 ` Soft Works 2022-05-24 13:58 ` [FFmpeg-devel] [PATCH v6 0/2] " ffmpegagent 2022-05-24 13:58 ` [FFmpeg-devel] [PATCH v6 1/2] avutil/wchar_filename, file_open: " softworkz 2022-05-24 20:55 ` Martin Storsjö 2022-05-24 13:58 ` [FFmpeg-devel] [PATCH v6 2/2] avformat/os_support: " softworkz 2022-05-24 20:58 ` Martin Storsjö 2022-05-24 22:12 ` Soft Works 2022-05-25 7:09 ` Martin Storsjö 2022-05-24 22:20 ` [FFmpeg-devel] [PATCH v7 0/3] " ffmpegagent 2022-05-24 22:20 ` [FFmpeg-devel] [PATCH v7 1/3] avutil/wchar_filename, file_open: " softworkz 2022-05-24 22:20 ` [FFmpeg-devel] [PATCH v7 2/3] avformat/os_support: " softworkz 2022-05-25 14:47 ` nil-admirari 2022-05-25 15:28 ` Soft Works 2022-05-25 19:17 ` nil-admirari 2022-05-26 5:09 ` Soft Works 2022-05-25 18:50 ` Martin Storsjö 2022-05-24 22:20 ` [FFmpeg-devel] [PATCH v7 3/3] avformat/file: remove _WIN32 condition softworkz 2022-05-25 7:34 ` [FFmpeg-devel] [PATCH v7 0/3] Support long file names on Windows Martin Storsjö 2022-05-26 9:28 ` [FFmpeg-devel] [PATCH v8 " ffmpegagent 2022-05-26 9:28 ` [FFmpeg-devel] [PATCH v8 1/3] avutil/wchar_filename, file_open: " softworkz 2022-05-26 9:28 ` [FFmpeg-devel] [PATCH v8 2/3] avformat/os_support: " softworkz 2022-05-26 9:28 ` [FFmpeg-devel] [PATCH v8 3/3] avformat/file: remove _WIN32 condition softworkz 2022-05-26 21:26 ` [FFmpeg-devel] [PATCH v8 0/3] Support long file names on Windows Martin Storsjö 2022-06-09 10:03 ` Martin Storsjö 2022-06-09 19:37 ` nil-admirari 2022-06-09 20:15 ` Soft Works 2022-06-09 20:22 ` nil-admirari 2022-06-09 21:32 ` Soft Works 2022-06-09 20:21 ` Martin Storsjö 2022-06-09 20:57 ` nil-admirari 2022-06-09 21:02 ` Martin Storsjö 2022-06-13 16:42 ` nil-admirari 2022-06-09 21:03 ` Soft Works
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=DM8P223MB03654CA8C7AF59E21C20F976BACC9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \ --to=softworkz@hotmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git