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
Attachment:
signature.asc
Description: This is a digitally signed message part