On Sun, 6 Aug 2017 08:57:41 +0300 Daniel Zaoui <[email protected]> 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 must know the > offset where the operations strings begin. So you must have a 64b value. yes. but in this case it's local within the process. it has to be. the pointer is dereferenced. only talking about THIS case. :) > On Sun, 6 Aug 2017 11:31:36 +0900 > Carsten Haitzler (The Rasterman) <[email protected]> wrote: > > > 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
