Am 18.11.2013 19:16, schrieb Julien Cristau:
On Sun, Nov 17, 2013 at 21:30:44 +0100, Jonas Petersen wrote:
Am 17.11.2013 20:20, schrieb Mouse:
I guess the sizeof comparison would not be necessary since the
condition should never meet with 64-bit longs.
Unless it's in a code fragment that's
Am 18.11.2013 00:33, schrieb Mouse:
*wide = new + ((unsigned long) (new *wide) 16 16);
The comment says Treating the comparison as a 1 and shifting it
avoids a conditional branch.
Only on architectures with conditional moves - and, on those, the
version using ? : is likely to compile
On Sun, Nov 17, 2013 at 21:30:44 +0100, Jonas Petersen wrote:
Am 17.11.2013 20:20, schrieb Mouse:
I guess the sizeof comparison would not be necessary since the
condition should never meet with 64-bit longs.
Unless it's in a code fragment that's used only on machines with
64-bit longs, it
On 16.11.2013 22:37, Jonas Petersen wrote:
By design the Xlib 32-bit internal request sequence numbers may wrap. There
is two locations within xcb_io.c that are not wrap-safe. The value of
last_flushed relies on the request to be sequential all the time. This is
not given when the sequence has
Am 17.11.2013 11:58, schrieb Uli Schlachter:
On 16.11.2013 22:37, Jonas Petersen wrote:
+ /* Set bit 8 of 'request' when a 32-bit wrap has just happened
+* so the sequence stays correct relatively to 'last_flushed'. */
1 32 does not set bit 8 and this doesn't set anything in
*wide = new + ((unsigned long) (new *wide) 16 16);
The comment says Treating the comparison as a 1 and shifting it
avoids a conditional branch.
Only on architectures with conditional moves - and, on those, the
version using ? : is likely to compile down to a conditional move
anyway. I
Am 17.11.2013 20:20, schrieb Mouse:
I guess the sizeof comparison would not be necessary since the
condition should never meet with 64-bit longs.
Unless it's in a code fragment that's used only on machines with
64-bit longs, it will; X runs on systems with 64-bit longs.
I meant the condition
Am 17.11.2013 21:30, schrieb Jonas Petersen:
Am 17.11.2013 20:20, schrieb Mouse:
And if it does, something is wrong anyway (from my understanding).
After all this is the trigger of the bug.
Does anyone know whether the bug triggers on systems with 64-bit longs?
I would say no, because there
Am 17.11.2013 20:20, schrieb Mouse:
*wide = new + ((unsigned long) (new *wide) 16 16);
The comment says Treating the comparison as a 1 and shifting it
avoids a conditional branch.
Only on architectures with conditional moves - and, on those, the
version using ? : is likely to compile
*wide = new + ((unsigned long) (new *wide) 16 16);
The comment says Treating the comparison as a 1 and shifting it
avoids a conditional branch.
Only on architectures with conditional moves - and, on those, the
version using ? : is likely to compile down to a conditional move
anyway.
By design the Xlib 32-bit internal request sequence numbers may wrap. There
is two locations within xcb_io.c that are not wrap-safe. The value of
last_flushed relies on the request to be sequential all the time. This is
not given when the sequence has just wrapped. Applications may then crash
with
By design the Xlib 32-bit internal request sequence numbers may wrap. There
is two locations within xcb_io.c that are not wrap-safe. The value of
last_flushed relies on the request to be sequential all the time. This is
not given when the sequence has just wrapped. Applications may then crash
with
By design the Xlib 32-bit internal request sequence numbers may wrap. There
is two locations within xcb_io.c that are not wrap-safe. The value of
last_flushed relies on the request to be sequential all the time. This is
not given when the sequence has just wrapped. Applications may then crash
with
13 matches
Mail list logo
