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

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Soft
> Works
> Sent: Tuesday, May 24, 2022 7:33 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> file_open: Support long file names on Windows
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Hendrik
> > Leppkes
> > Sent: Monday, May 23, 2022 7:12 PM
> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> > file_open: Support long file names on Windows
> >
> > On Mon, May 23, 2022 at 5:48 PM Soft Works <softworkz at hotmail.com>
> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> nil-
> > > > admirari at mailo.com
> > > > Sent: Monday, May 23, 2022 5:36 PM
> > > > To: ffmpeg-devel at ffmpeg.org
> > > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> > > > file_open: Support long file names on Windows
> > > >
> > > > >> Not possible for stat precisely because of function and struct
> > sharing
> > > > a
> > > > >> name.
> > > >
> > > > > That's exactly what is said above and before :-)
> > > >
> > > > My previous question was not answered, so I had to look up the
> answer
> > > > myself.
> > > >
> > > > > I'm actually wondering how does it even compile. All stat structs
> in
> > > > code
> > > > > become struct win32_stat, and all calls to stat become calls to
> > > > win32_stat,
> > > > > which in turn wraps _wstati64. But _wstati64 does not accept
> struct
> > > > win32_stat*,
> > > > > it accepts struct _stati64*. Content of these structs is probably
> > > > identical, but
> > > > > it should not matter: C is typed nominally, not structurally.
> > > >
> > > > Turns out C actually has a concept of compatible types:
> > > > https://en.cppreference.com/w/c/language/type.
> > > >
> > > > The problems is:
> > > > > they are both structure/union/enumeration types, and
> > > > > - (c99) if one is declared with a tag, the other must also be
> > declared
> > > > with the same tag.
> > > > > ...
> > > > > If two declarations refer to the same object or function and do
> not
> > use
> > > > compatible types,
> > > > > the behavior of the program is undefined.
> > > >
> > > > Your structure does not have the same tag as the CRT's one.
> > > > Are you sure you want to rely on undefined behaviour?
> > > >
> > > > I haven't compiled your code, but the following simple example:
> > > >
> > > > struct A { int a, b, c; };
> > > > struct B { int a, b, c; };
> > > > void printA(struct A *a);
> > > >
> > > > struct B b = { 1, 2, 3 };
> > > > printA(&b);
> > > >
> > > > generates a
> > > >
> > > > warning: passing argument 1 of ‘printA’ from incompatible pointer
> type
> > [-
> > > > Wincompatible-pointer-types]
> > > >     |     printA(&b);
> > > >     |            ^~
> > > >     |            |
> > > >     |            struct B *
> > > > note: expected ‘struct A *’ but argument is of type ‘struct B *’
> > > >     | void printA(struct A *a)
> > > >
> > > > Are you sure you wanna add a couple of similar warnings to the
> > project?
> > >
> > > This is not what's happening. No warnings, not even from clang
> > diagnostics
> > > with -Weverything.
> > >
> > >
> > > > Needless to repeat, _USE_32BIT_TIME_T is not supported.
> > >
> > > I don't think it ever was. Have you been compiling and using ffmpeg
> > > successfully with this?
> > >
> >
> > _USE_32BIT_TIME_T is actually the default for 32-bit mingw-w64 builds,
> > so its certainly a situation on windows that needs to work - and does
> > in master.
> 
> Are you sure? It is not the default for 32 bit builds with MSVC.

Sorry, you're right. I found it. It's in _mingw.h.

I'll update the patch.

Thanks,
sw