Re: [FFmpeg-devel] [PATCH] avutil/internal: Document ugly looking windows specific file related function renaming
On Thu, Feb 02, 2017 at 09:07:25AM +0100, wm4 wrote: > On Wed, 1 Feb 2017 22:24:14 +0100 > Michael Niedermayer wrote: > > > On Wed, Feb 01, 2017 at 03:26:45PM +0100, wm4 wrote: > > > On Wed, 1 Feb 2017 14:35:50 +0100 > > > Michael Niedermayer wrote: > > > > > > > Found-by: ubitux > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavutil/internal.h | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/libavutil/internal.h b/libavutil/internal.h > > > > index a19975d474..e97034887b 100644 > > > > --- a/libavutil/internal.h > > > > +++ b/libavutil/internal.h > > > > @@ -243,8 +243,12 @@ void avpriv_request_sample(void *avc, > > > > #pragma comment(linker, "/include:" EXTERN_PREFIX "avpriv_snprintf") > > > > #endif > > > > > > > > +// Rename shared function (both use and implementation of them) so > > > > they are not shared > > > > +// and each library carries its own copy of a implementation, this is > > > > needed as > > > > > > So why are they not appropriately named in the first place? > > > > > > > +// the fd numbers are not transportable between libs on windows > > > > > > AFAIK they are, as long as they're linked to the same stdlib (which > > > probably is the case for libav*). > > > > here is the commit introducing the first function using this system. > > I belive its commit message is quite good and explains the reasoning. > > Beyond that iam the wrong one to discuss this with, iam not a windows > > developer and i didnt design this, which is not to say i like or > > dislike it. I just added one function IIRC and i wanted to document it > > as ubitux seemed to be confused for a moment when seeing it the first > > time > > > > commit e743e7ae6ee7e535c4394bec6fe6650d2b0dbf65 > > Author: Martin Storsjö > > Date: Fri Aug 9 11:06:46 2013 +0300 > > > > libavutil: Make avpriv_open a library-internal function on msvcrt > > > > Add one copy of the function into each of the libraries, similarly > > to what we do for log2_tab. When using static libs, only one > > copy of the file_open.o object file gets included, while when > > using shared libraries, each of them get a copy of its own. > > > > This fixes DLL builds with a statically linked C runtime, where > > each DLL effectively has got its own instance of the C runtime, > > where file descriptors can't be shared across runtimes. > > > > On systems not using msvcrt, the function is not duplicated. > > > > [...] > > Maybe this would be better: > > // If each libav* DLL is statically linked to the C runtime, FDs can > // not be used across library boundaries. Duplicate these functions in > // each DLL to avoid this problem. LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/internal: Document ugly looking windows specific file related function renaming
On Wed, 1 Feb 2017 22:24:14 +0100 Michael Niedermayer wrote: > On Wed, Feb 01, 2017 at 03:26:45PM +0100, wm4 wrote: > > On Wed, 1 Feb 2017 14:35:50 +0100 > > Michael Niedermayer wrote: > > > > > Found-by: ubitux > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavutil/internal.h | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/libavutil/internal.h b/libavutil/internal.h > > > index a19975d474..e97034887b 100644 > > > --- a/libavutil/internal.h > > > +++ b/libavutil/internal.h > > > @@ -243,8 +243,12 @@ void avpriv_request_sample(void *avc, > > > #pragma comment(linker, "/include:" EXTERN_PREFIX "avpriv_snprintf") > > > #endif > > > > > > +// Rename shared function (both use and implementation of them) so they > > > are not shared > > > +// and each library carries its own copy of a implementation, this is > > > needed as > > > > So why are they not appropriately named in the first place? > > > > > +// the fd numbers are not transportable between libs on windows > > > > AFAIK they are, as long as they're linked to the same stdlib (which > > probably is the case for libav*). > > here is the commit introducing the first function using this system. > I belive its commit message is quite good and explains the reasoning. > Beyond that iam the wrong one to discuss this with, iam not a windows > developer and i didnt design this, which is not to say i like or > dislike it. I just added one function IIRC and i wanted to document it > as ubitux seemed to be confused for a moment when seeing it the first > time > > commit e743e7ae6ee7e535c4394bec6fe6650d2b0dbf65 > Author: Martin Storsjö > Date: Fri Aug 9 11:06:46 2013 +0300 > > libavutil: Make avpriv_open a library-internal function on msvcrt > > Add one copy of the function into each of the libraries, similarly > to what we do for log2_tab. When using static libs, only one > copy of the file_open.o object file gets included, while when > using shared libraries, each of them get a copy of its own. > > This fixes DLL builds with a statically linked C runtime, where > each DLL effectively has got its own instance of the C runtime, > where file descriptors can't be shared across runtimes. > > On systems not using msvcrt, the function is not duplicated. > > [...] Maybe this would be better: // If each libav* DLL is statically linked to the C runtime, FDs can // not be used across library boundaries. Duplicate these functions in // each DLL to avoid this problem. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/internal: Document ugly looking windows specific file related function renaming
On Wed, Feb 01, 2017 at 03:26:45PM +0100, wm4 wrote: > On Wed, 1 Feb 2017 14:35:50 +0100 > Michael Niedermayer wrote: > > > Found-by: ubitux > > Signed-off-by: Michael Niedermayer > > --- > > libavutil/internal.h | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/libavutil/internal.h b/libavutil/internal.h > > index a19975d474..e97034887b 100644 > > --- a/libavutil/internal.h > > +++ b/libavutil/internal.h > > @@ -243,8 +243,12 @@ void avpriv_request_sample(void *avc, > > #pragma comment(linker, "/include:" EXTERN_PREFIX "avpriv_snprintf") > > #endif > > > > +// Rename shared function (both use and implementation of them) so they > > are not shared > > +// and each library carries its own copy of a implementation, this is > > needed as > > So why are they not appropriately named in the first place? > > > +// the fd numbers are not transportable between libs on windows > > AFAIK they are, as long as they're linked to the same stdlib (which > probably is the case for libav*). here is the commit introducing the first function using this system. I belive its commit message is quite good and explains the reasoning. Beyond that iam the wrong one to discuss this with, iam not a windows developer and i didnt design this, which is not to say i like or dislike it. I just added one function IIRC and i wanted to document it as ubitux seemed to be confused for a moment when seeing it the first time commit e743e7ae6ee7e535c4394bec6fe6650d2b0dbf65 Author: Martin Storsjö Date: Fri Aug 9 11:06:46 2013 +0300 libavutil: Make avpriv_open a library-internal function on msvcrt Add one copy of the function into each of the libraries, similarly to what we do for log2_tab. When using static libs, only one copy of the file_open.o object file gets included, while when using shared libraries, each of them get a copy of its own. This fixes DLL builds with a statically linked C runtime, where each DLL effectively has got its own instance of the C runtime, where file descriptors can't be shared across runtimes. On systems not using msvcrt, the function is not duplicated. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/internal: Document ugly looking windows specific file related function renaming
On Wed, 1 Feb 2017 14:35:50 +0100 Michael Niedermayer wrote: > Found-by: ubitux > Signed-off-by: Michael Niedermayer > --- > libavutil/internal.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/libavutil/internal.h b/libavutil/internal.h > index a19975d474..e97034887b 100644 > --- a/libavutil/internal.h > +++ b/libavutil/internal.h > @@ -243,8 +243,12 @@ void avpriv_request_sample(void *avc, > #pragma comment(linker, "/include:" EXTERN_PREFIX "avpriv_snprintf") > #endif > > +// Rename shared function (both use and implementation of them) so they are > not shared > +// and each library carries its own copy of a implementation, this is needed > as So why are they not appropriately named in the first place? > +// the fd numbers are not transportable between libs on windows AFAIK they are, as long as they're linked to the same stdlib (which probably is the case for libav*). > #define avpriv_open ff_open > #define avpriv_tempfile ff_tempfile > + > #define PTRDIFF_SPECIFIER "Id" > #define SIZE_SPECIFIER "Iu" > #else ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
