On 5/28/05, Diego 'Flameeyes' Petten=F2 <flameeyes@...> wrote:
> On Sunday 29 May 2005 00:36, Miguel Freitas wrote:
> > > #define LE_64(x) ((uint64_t)((uint64_t)(((uint8_t*)(x))) << 56) | =
> > ok, but isn't there too many uint64_t's here? i mean, we must cast to
> > 64 bits before shifting, but we don't need to do it again before
> > or'ing. do we?
> We shouldn't need them but... better safe than sorry, we can't be sure ho=
> different version of gcc will treat them, and the cast isn't a time consu=
> step so that shouldn't be too much of a problem.
i'm usually on the "better safe than sorry" camp, but this time i
think the extra uint64_t will only make these macros clumsy... we have
n operands that have already been promoted to 64 bits, i can't see why
we would need to further typecast them. imho any compiler that takes
64 bits operands and OR then into a 32 bits result should be
considered broken (i doubt any gcc would fail like that).
anyway, thank you very much for showing this. i wonder how people on
non-x86 archs could use xine at all. quite some demuxers must depend
on these macros.
i will do some tests here and commit a fix soon...