On Sat, 5 Aug 2017 19:47:41 +0300 Daniel Zaoui <[email protected]> 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. 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 :-) yeah - but it doesnt even need the uint64_t stuff - just ptr to a ptr... size is already known as its the size of a native ptr :) > On Thu, 3 Aug 2017 09:11:43 +0900 > Carsten Haitzler (The Rasterman) <[email protected]> wrote: > > > On Wed, 2 Aug 2017 20:54:20 +0300 Daniel Zaoui > > <[email protected]> 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 <[email protected]> wrote: > > > > > > > raster pushed a commit to branch master. > > > > > > > > http://git.enlightenment.org/core/efl.git/commit/?id=470b48d63cfcbd08323634fa395bdbb1b93b8e2d > > > > > > > > commit 470b48d63cfcbd08323634fa395bdbb1b93b8e2d > > > > Author: Carsten Haitzler (Rasterman) <[email protected]> > > > > 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 > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
