[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lock warnings on mingw
From: |
Bruno Haible |
Subject: |
Re: lock warnings on mingw |
Date: |
Wed, 18 Jun 2008 02:36:05 +0200 |
User-agent: |
KMail/1.5.4 |
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
- strsignal on mingw, Eric Blake, 2008/06/17
- Re: lock, tls, and single-threaded applications, Bruno Haible, 2008/06/17
- Re: lock, tls, and single-threaded applications, Eric Blake, 2008/06/17
- Re: lock, tls, and single-threaded applications, Bruno Haible, 2008/06/18
- Re: lock, tls, and single-threaded applications, Jim Meyering, 2008/06/18
- Re: lock, tls, and single-threaded applications, Bruno Haible, 2008/06/18
Re: tls license, Bruno Haible, 2008/06/17
Re: lock warnings on mingw,
Bruno Haible <=
Re: tls warnings on mingw, Bruno Haible, 2008/06/17
[OT] VCS behavior [Re: strsignal on mingw], Eric Blake, 2008/06/18