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.

On Sun, 6 Aug 2017 11:31:36 +0900
Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:

> On Sat, 5 Aug 2017 19:47:41 +0300 Daniel Zaoui
> <jackdani...@eyomi.org> 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) <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

Reply via email to