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 that you can remove the second swap too. I just forgot to mention it in my first mail, although I aimed :-)
On Thu, 3 Aug 2017 09:11:43 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > On Wed, 2 Aug 2017 20:54:20 +0300 Daniel Zaoui > <jackdani...@eyomi.org> 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 over the network (ipc included as network here). this > ptr that buf points to... is never transported anywhere. it can't be > as its dereferenced as a raw ptr. so why even use the 64bit type just > have by ptr point to the info ptr and the size will be a std pointer > size within that process - be it 32 or 64bit ... so it chances based > on architecture (32 vs 64bit) but that's fine... > > > 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 built. > > > > JackDanielZ > > > > On Wed, 02 Aug 2017 06:43:01 -0700 > > Carsten Haitzler <ras...@rasterman.com> wrote: > > > > > raster pushed a commit to branch master. > > > > > > http://git.enlightenment.org/core/efl.git/commit/?id=470b48d63cfcbd08323634fa395bdbb1b93b8e2d > > > > > > commit 470b48d63cfcbd08323634fa395bdbb1b93b8e2d > > > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> > > > Date: Wed Aug 2 22:41:54 2017 +0900 > > > > > > eina debug - new debug infra - comment out and make a note on > > > bad endian > > > bad endian... code... see the comment in the src about why i > > > think this is bad as obviously the buffer pointed to is a 64bit > > > type always that is a pointer to something... > > > --- > > > src/lib/eina/eina_debug.c | 13 ++++++++++++- > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > diff --git a/src/lib/eina/eina_debug.c b/src/lib/eina/eina_debug.c > > > index f0d101e864..b71a263670 100644 > > > --- a/src/lib/eina/eina_debug.c > > > +++ b/src/lib/eina/eina_debug.c > > > @@ -311,7 +311,18 @@ _callbacks_register_cb(Eina_Debug_Session > > > *session, int src_id EINA_UNUSED, void > > > uint64_t info_64; > > > memcpy(&info_64, buffer, sizeof(uint64_t)); > > > - info_64 = SWAP_64(info_64); > > > + // This is super dodgey. like really dodgey. it HAPPENS to > > > work on > > > + // little endian. definitely on 64bit because the SWAP is a > > > nop and the > > > + // pointer the buffer points to can be just used as-is, but if > > > this > > > + // was bigendian the swap would mess up the ptr and crash (on > > > 64bit) as > > > + // it'd swap everything around. on little endian 32bit it will > > > happen to > > > + // work as it takes the lower 32bits, but on big endian... > > > bork bork. > > > + // > > > + // so obviously... don't swap, then it'll always take the > > > LOWER 32bits > > > + // on 32bit and should work... since buffer obviously is > > > pointing to > > > + // a 64bit type that contains a pointer to something... and on > > > 64bit it'll > > > + // just work as-is as sizes match. > > > +// info_64 = SWAP_64(info_64); > > > info = (_opcode_reply_info *)info_64; > > > > > > if (!info) return EINA_FALSE; > > > > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
