media-video/sswf-1.8.0's src/lib/libsswf_util.c contains the "swap" function which "Swaps the content of two buffers". This function casts void* to int32_t without checking void* size. When compiling on amd64, void* has a size of 64 bits, so I get the error message libsswf_util.c++: In function 'void sswf::swap(void*, void*, size_t)': libsswf_util.c++:512: error: cast from 'void*' to 'int32_t' loses precision libsswf_util.c++:512: error: cast from 'void*' to 'int32_t' loses precision Steps to reproduce: 1. Buy an amd64 and install Gentoo-amd64 2. emerge sswf I'm filing a patch.
Created attachment 113883 [details, diff] Evaluate the size of void* while executing sswf::patch() This patch is intended to work on 32 and 64-bit platforms, provided int64_t is defined.
Created attachment 113887 [details] sswf-1.8.0.ebuild I've tested it with 32bit, and noticed no regressions.. so amd64, if the patch looks allright to you, go ahead.
I sended info on this bug to Alexis Wilke, author of sswf. Here is his reply: Hi Fabio, Yes indeed. The cast to int32_t of pointers is not a good idea. I changed that with intptr_t. This prevents the warning. Now for your fix you need to use 7 and not 4 in your expressions. if(sizeof(void *) == 8 && (size & 7) == 0 && (((intptr_t) s1) & 7) == 0 && (((intptr_t) s2) & 7) == 0) { It is likely to work fine with 4, especially on an INTEL processor which usually does not generate an error when accessing data whatever the address. But 7 is what is correct, you must ensure that all three bits are zero, especially for Macs and IRIX systems. I will put the change up on our FTP very soon. Thank you for the compliments too 8-) Always welcome! Alexis
seems like this is fixed upstream, putting ftp://ftp.m2osw.com/sswf/sswf-1.8.0/sswf-1.8.0-src.tar.bz2 (upstream ftp) in distfiles and emerging sswf works for me, the sswf-1.8.0-src.tar.bz2 on the gentoo mirrors doesn't have the patch yet though
Adding media-video to CC, please have a look at comment #4 :>
(In reply to comment #4) > seems like this is fixed upstream, putting > ftp://ftp.m2osw.com/sswf/sswf-1.8.0/sswf-1.8.0-src.tar.bz2 (upstream ftp) in > distfiles and emerging sswf works for me, the sswf-1.8.0-src.tar.bz2 on the > gentoo mirrors doesn't have the patch yet though ....... changing the tarball while keeping the same name will only break our digests......
Created attachment 116311 [details, diff] upstream's 64bit patch Well ok, I guess a simple redigest wouldn't fix it - so here's the fix used by upstream, nearly the same previously attached to this bug but with the fix mentioned in comment #3 There are actually more changes, but the whole diff of the new source and the tarball on the gentoo mirrors resulted in a 1.8M file ;>
(In reply to comment #6) > (In reply to comment #4) > > seems like this is fixed upstream, putting > > ftp://ftp.m2osw.com/sswf/sswf-1.8.0/sswf-1.8.0-src.tar.bz2 (upstream ftp) in > > distfiles and emerging sswf works for me, the sswf-1.8.0-src.tar.bz2 on the > > gentoo mirrors doesn't have the patch yet though > > > ....... changing the tarball while keeping the same name will only break our > digests...... > Yeah, it's lame. Lucky for us they provide both .tar.bz2 and tar.gz so.. 17:33 <+CIA-11> drac * gentoo-x86/media-video/sswf/ (ChangeLog sswf-1.8.0.ebuild files/digest-sswf-1.8.0): 17:33 <+CIA-11> Change tarball from .tar.bz2 to .tar.gz to get a 64bit patch because upstream didn't version bump. 17:33 <+CIA-11> (Portage version: 2.1.2.3) So we should have the patch now. AMD64, reopen if this still doesn't work for you.
