Build failure cross-compiling for x86_64-w64-mingw32 target

Thanks. Clearly your pthread_t type is not a scalar type. I found this post that might be relevant: http://sourceware.org/ml/pthreads-win32/2011/msg00000.html

Can you think of a way to define curl_thread_t_null differently so that the code works for you and other pthread implementations?

Alternatively we change the internal API to not do comparisons with the pthread_t value, which seems to be the proper way to do this.

Are you able to provide a patch

I don't see any POSIX-compliant way to define a null pthread_t. Perhaps libcurl could use a pthread_t* instead? I could probably provide a patch, but I need to know which approach/solution is acceptable.

Sure, using a pthread_t could work. The parent function then will need to copy the pointer if it isn't NULL.

Here's an initial draft. I tried to make it API-compatible. Let me know what you think.

Oh, clever move there. I think it looks good enough and I'm currently running the test suite to verify that it doesn't cause any major surprises. Looks fine!

Thanks. Do you have another iteration of the patch in mind or should we go with that?

If it works, go ahead and go ahead with that one! I was just expecting some issue since I don't regularly do libcurl code and my last patch got ignored ;)

Thanks a lot for your report and patch! I've merged and pushed your patch as commit e8b57d1e849c8. You'll notice that I moved a brace and updated the commit message.

Case closed

I just wanted to give my two pennies worth as I have some Win32 pthread experience and am hoping to bring that to curl at some point in the future.

Given that the malloc's of t and ac could fail independently (although fairly unlikely) but then be caught by the if after the ac malloc, wouldn't it be better to use Curl_safefree() instead of free?

Ah you're right, to better work with our own memory debug system and runtests -t etc, Curl_safefree() is better. I'll fix that. Thanks!

free() should be safe with NULL values.