On Wed, 2005-09-14 at 10:29 +0200, Tristan Tarrant wrote: > On Wed, 2005-09-14 at 18:11 +1000, James Livingston wrote: > > > The problem is that bit of code is trying to store a pointer in an > > integer variable, which is non-portable and a Bad Thing To Do. If it did > > compile, it would crash due to the fact that there is no way to have a > > 32 bit integer storing a 64 bit pointer. > > > > Unfortunately I don't know enough about the daap code to fix it. > > 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 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. But, if it doesn't compile for some people, then I'll do it some other way. I'll fix it & commit something tonight. -charlie _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
