Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Soft Works <softworkz@hotmail.com>
To: "Martin Storsjö" <martin@martin.st>
Cc: Hendrik Leppkes <h.leppkes@gmail.com>,
	FFmpeg development discussions and patches
	<ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows
Date: Tue, 24 May 2022 11:15:31 +0000
Message-ID: <DM8P223MB0365C1DF74FCED2A8906F49ABAD79@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <cb77ee55-e8df-63bd-f79-4b60d7fda47c@martin.st>



> -----Original Message-----
> From: Martin Storsjö <martin@martin.st>
> Sent: Tuesday, May 24, 2022 12:26 PM
> To: Soft Works <softworkz@hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>;
> Hendrik Leppkes <h.leppkes@gmail.com>
> Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
> long file names on Windows
> 
> On Tue, 24 May 2022, Soft Works wrote:
> 
> >> -----Original Message-----
> >> From: Martin Storsjö <martin@martin.st>
> >> Sent: Tuesday, May 24, 2022 11:23 AM
> >> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> >> Cc: softworkz <softworkz@hotmail.com>; Hendrik Leppkes
> >> <h.leppkes@gmail.com>
> >> Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
> >> long file names on Windows
> >>
> >> On Tue, 24 May 2022, softworkz wrote:
> >>
> >>> From: softworkz <softworkz@hotmail.com>
> >>>
> >>> Signed-off-by: softworkz <softworkz@hotmail.com>
> >>> ---
> >>> libavformat/os_support.h | 16 +++++++++++-----
> >>> 1 file changed, 11 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> >>> index 5e6b32d2dc..d4c07803a5 100644
> >>> --- a/libavformat/os_support.h
> >>> +++ b/libavformat/os_support.h
> >>> @@ -49,7 +49,13 @@
> >>> #  ifdef stat
> >>> #   undef stat
> >>> #  endif
> >>> -#  define stat _stati64
> >>> +#  define stat win32_stat
> >>> +
> >>> +    struct win32_stat
> >>> +    {
> >>> +        struct _stati64;
> >>> +    };
> >>
> >> Is it possible to work around this issue by doing "#define stat(a,b)"
> >> which only should apply on the function, not to the struct?
> >
> > How could this be possible? A define is only doing string replacements,
> > so I wouldn't know how it could be restricted to the function, but
> > not the struct.
> 
> If unsure about a tool feature, please try it out for yourself.

I did :-)
(very extensively in fact)

> Yes, a
> define is only a string replacement, but a define with parameters only
> matches the string occurs with parenthesis afterwards. 

Yes, that's true, but we need to rename both, the function and the
struct, not just the function.


Your example doesn't quite match the situation.

// Let's start with the pre-requisites which cannot be changed
// Posix definitions (stat.h)
struct stat {
 	int a, b, c;
};

// This is the regular definition
int stat(char *fileName, struct stat *par)

// With your define, we replace the function, but not the 
// struct. So we would call the WinAPI function with 
// the wrong struct.
#define stat(a, b) win32_stat(a, b)

// I don't know why you have this in your example at
// this place. It comes from some include file and
// it is not the one we need to use.
// if you mean to redefine it here: that was my previous
// approach. You need to copy the struct (but rename it)
struct stat {
 	int a, b, c;
};

// ----------------- other example:

// This function needs to call the windows function,
// so we cannot use the regular stat struct as parameter
void win32_stat(struct stat *st, const char* filename);



> So here, the stat -> win32_stat rewrite only applied on the function
> declaration and call, but not on the structs.

Exactly, but the struct must be rewritten as well and this is not
possible. 

Neither this:

#define stat _stati64
#define stat(a, b) win32_stat(a, b)

nor this:

#define stat(a, b) win32_stat(a, b)
#define stat _stati64

is working (yes, I tried ;-)

> This, as the article itself clearly declares, is a C language extension.
> GCC allows it in mingw mode

Yes I had read about that.

> but Clang doesn't. (It's possible to use it
> in Clang too if you enable it with -fms-extensions though.)

Is it possible to compile ffmpeg for Windows using Clang?
And if yes, does it even work without that flag?
(assuming it was introduced in order to be able to 
compile Windows stuff).


Thanks again,
sw
_______________________________________________
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".

  reply	other threads:[~2022-05-24 11:16 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
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 [this message]
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=DM8P223MB0365C1DF74FCED2A8906F49ABAD79@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \
    --to=softworkz@hotmail.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    --cc=h.leppkes@gmail.com \
    --cc=martin@martin.st \
    /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