Rémi Cardona wrote:
> Andrew Haley a écrit :
>> Or it may be that gdb is misleading you.
>>
>> How do you know that the parameters to this call are wrong?
>
> Because the Xlib call does not return what I expect it to. After the
> shuffling I described, gdb gives me all the right values (which is not
> proof on its own, I agree) but the Xlib call returns the right data and
> the rest of the program works as expected.
>
>> The .i file after preprocessing would help. Use -save-temps to get it.
>
> Attached. The diff between atoms.i before and after my patch only shows
> the code change (around line 10109), the rest is strictly identical.
>
>> Are you using -Wall ?
>
> Yes, no warning of any sort at build or link time.
Are you using optimization? I think can see at least one bug in this function.
((CARD32 *)data)[i] = ((long *)retval)[i];
You're aliasing an unsigned int and an unsigned long.
This is an aliasing violation.
Try compiling with -fno-strict-aliasing.
Andrew.
