On Sun, 6 Aug 2017 08:57:41 +0300 Daniel Zaoui said:
> In the case of a local application registering opcodes, you are right, as it
> is the same device. In the case of a remote debugger, you have no clue. You
> could have a 64b machine debugging a 32b machine. The daemon
In the case of a local application registering opcodes, you are right, as it is
the same device. In the case of a remote debugger, you have no clue. You could
have a 64b machine debugging a 32b machine. The daemon must know the offset
where the operations strings begin.
So you must have a 64b
On Sat, 5 Aug 2017 19:47:41 +0300 Daniel Zaoui said:
> The opcodes requester just needs this pointer in the packet to determine
> which structure it needs to fill with the opcodes when the response comes
> back. The daemon doesn't use it at all. Only the requester does.
The opcodes requester just needs this pointer in the packet to determine which
structure it needs to fill with the opcodes when the response comes back. The
daemon doesn't use it at all. Only the requester does.
That's why it was useless to swap it from the beginning. And that's why I told
you
On Wed, 2 Aug 2017 20:54:20 +0300 Daniel Zaoui said:
actually on further looking all the 64bit thing you do isnt' needed. you ONLY
need this for sorting in files or over the network where different apps may be
32 or 64bit that are reading/writing to the file or talking
On Wed, 2 Aug 2017 20:54:20 +0300 Daniel Zaoui said:
> Hello Master,
>
> Thanks for the fix.
>
> If I understand well, the problem is that the wrong bytes will be taken
> during the cast right? I understand there may be an issue on big endian 32
> bits but why would it
Hello Master,
Thanks for the fix.
If I understand well, the problem is that the wrong bytes will be taken during
the cast right? I understand there may be an issue on big endian 32 bits but
why would it crash on 64 bits?
If you remove the swap, you should remove the swap where the request is