> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Soft > Works > Sent: Tuesday, May 24, 2022 7:33 AM > To: FFmpeg development discussions and patches <ffmpeg-devel@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-boun...@ffmpeg.org> On Behalf Of > Hendrik > > Leppkes > > Sent: Monday, May 23, 2022 7:12 PM > > To: FFmpeg development discussions and patches <ffmpeg-devel@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 <softwo...@hotmail.com> > wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > nil- > > > > admir...@mailo.com > > > > Sent: Monday, May 23, 2022 5:36 PM > > > > To: ffmpeg-devel@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 _______________________________________________ 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".