Re: xquartz dereferencing a NULL pointer (patch 2)
Matthieu Herrb wrote: Simon Thum wrote: Tiago Vignatti wrote: http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Does we have this kind of thing in C libraries? It would be useful. If I got it right, that's posix + pthreads functionality specialized for an amtel platform. So in general, yes. Sorry, but no. These macros are not standard at all, and without explicit using of some kind of lock, there no portable way to handle atomicity in pthreads afaik. Actually, I tried to argue that the functionality is covered by posix+pthreads, as far as is needed at least. So 'yes' meant yes, we've got that kind of thing covered, in some sense. I didn't intend to argue for those macros in X at all. X should stick to pthreads of course. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xquartz dereferencing a NULL pointer (patch 2)
Tiago Vignatti wrote: http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Does we have this kind of thing in C libraries? It would be useful. If I got it right, that's posix + pthreads functionality specialized for an amtel platform. So in general, yes. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xquartz dereferencing a NULL pointer (patch 2)
Simon Thum wrote: Tiago Vignatti wrote: http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Does we have this kind of thing in C libraries? It would be useful. If I got it right, that's posix + pthreads functionality specialized for an amtel platform. So in general, yes. Sorry, but no. These macros are not standard at all, and without explicit using of some kind of lock, there no portable way to handle atomicity in pthreads afaik. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xquartz dereferencing a NULL pointer (patch 2)
Simon Thum wrote: newtail = (oldtail + 1) % QUEUE_SIZE; miEventQueue.tail = newtail; becoming miEventQueue.tail++; miEventQueue.tail |= QUEUE_SIZE - 1; Er, shouldn't this be = ? I don't think a compiler should be doing this to a non-local store. It could probably be considered a bug. C doesn't really have a memory model but few rules likely to forbid this. I didn't check, but I'd be highly surprised by this being legal. Unless an lvalue is declared volatile, the compiler is free to generate code which modifies it as and when it sees fit, so long as it has the correct value in the end. In the meantime, it can freely store arbitrary data there if it wishes. This is why the volatile keyword was added to the ANSI C standard: so that the compiler could optimise memory access as it saw fit, while providing an opt-out for the cases where intermediate values are significant (signals, interrupts, memory-mapped I/O, threads, etc). -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
