On Wed, 2005-09-14 at 07:11 -0400, Charles Schmidt wrote:
> On Wed, 2005-09-14 at 10:29 +0200, Tristan Tarrant wrote:
> > The code is doubly wrong in fact.
> > I've checked some docs on DAAP and it seems MPER (playlist persistent
> > id) is 8 bytes, but the code is casting the pointer to a 32bit int and
> > recasting it as a 64bit int. Am I wrong in assuming that the code is
> > using the pointers just for convenience ? Can't these IDs be generated
> > somehow and use an internal lookup table.
> > Fun fun fun.
>
> Works For Me. Pointers are 4 bytes, 32bit integers are 4 bytes. Cast
^ ^ ^
Only on (the vast majority of) 32 bit systems - which leads to the
problems that are occurring when trying to use this on a 64 bit system.> the 32bit int into a 64bit int and it fills up the rest of the space > with zeros, which is fine. So now you've got a unique 64bit > representation of the source. Correct me if I'm wrong - that was my > thinking behind the code. Furthermore, when the time comes later, you > can convert the int back to a pointer to find out what source we're > talking about. glib contains some handy macros for storing a 32 bit integer in a pointer variable (which is guaranteed to work), such as GPOINTER_TO_INT and GINT_TO_POINTER. Storing a pointer in an integer variable isn't guaranteed to work at all, even on 32 bit systems (although it usually does in practise). Cheers, James "Doc" Livingston -- There's no reason to become alarmed, and we hope you'll enjoy the rest of your flight. By the way, is there anyone on board who knows how to fly a plane? -- Airplane
signature.asc
Description: This is a digitally signed message part
_______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
