On Thu, 21 Jun 2012, Martin Storsjö wrote:
On Tue, 19 Jun 2012, Martin Storsjö wrote:
On Tue, 19 Jun 2012, Ronald S. Bultje wrote:
Hi,
On Tue, Jun 19, 2012 at 6:29 AM, Martin Storsjö <[email protected]> wrote:
This avoids warnings if there already exists a definition.
This is the case on windows, where the getaddrinfo isn't available
and linked to (and we use our fallbacks instead, which actually
try to use the proper getaddrinfo version if found at runtime),
but gai_strerror still exists as a define.
---
libavformat/network.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/network.h b/libavformat/network.h
index 72d01d2..8f7c19a 100644
--- a/libavformat/network.h
+++ b/libavformat/network.h
@@ -150,6 +150,7 @@ const char *ff_gai_strerror(int ecode);
#define getaddrinfo ff_getaddrinfo
#define freeaddrinfo ff_freeaddrinfo
#define getnameinfo ff_getnameinfo
+#undef gai_strerror
#define gai_strerror ff_gai_strerror
#endif
It seems broken to workaround a Windows feature (providing
gai_strerror) by using our own?
Yes, perhaps.
The mingw implementation of the function is unfortunately not threadsafe
though, although the MSVC version might be.
Do you think we should do this only for #ifndef gai_strerror?
Any other opinions on this, or can I go ahead with this patch?
Our own fallback version of this particular function should be just as good
as any other, and our version is threadsafe. And if you do a build that links
straight to getaddrinfo, none of these fallbacks are used.
After looking more into the issue... Not only is the mingw32
implementation of gai_strerror thread-unsafe, microsoft also documents
that their version of the function (in ws2_32.dll) explicitly is not
threadsafe and shouldn't be used. Therefore, I'll take Måns LGTM for this
patch and apply it.
Later, I'll make a patch for using our own fallback version of this
function on windows (and to improve it) even if we use the system
getaddrinfo directly, since we don't want libavformat to not be
threadsafe.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
