[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 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.

But it could be made working with the way that I'm using in my current 
patchset (with a conditional define). So that's not really the question.

The primary question is whether the (admittedly) ugly way I'm
using is acceptable at all.

Suggestions are very welcome ;-) 
Would you have an idea perhaps?

Thanks,
softworkz