Eric Blake wrote:
> The mingw headers for <windows.h> currently have a bug, where
> Interlocked{In,De}
> crement are defined as taking LPLONG (long *) rather than the Microsoft
> documentation [1] of LONG volatile *, triggering compiler warnings when
> passing
> in a pointer to volatile data. Is it acceptable to add macros to lock.h to
> work around this mingw deficiency when USE_WIN32_THREADS?
I vote against it. If you cast away the 'volatile', the compiler is allowed
to cache some intermediate values in registers, effectively turning the
supposedly atomic operation into a non-atomic one. I find it better to live
with the warnings rather than to introduce a bug in our code that would stay
a bug even after mingw's bug is fixed.
> [1] http://msdn.microsoft.com/en-us/library/ms683614(VS.85).aspx
>
> ../../lib/lock.c: In function `glthread_lock_lock':
> ../../lib/lock.c:550: warning: passing arg 1 of `InterlockedIncrement'
> discards qualifiers from pointer target type
You have diagnosed it as a mingw header bug; please report it to the mingw
maintainers if you have time.
Bruno
