[Ffmpeg-cvslog] r8608 - in trunk: Changelog doc/ffmpeg-doc.texi libavcodec/Makefile libavcodec/allcodecs.c libavcodec/avcodec.h libavcodec/tiff.c libavcodec/tiff.h libavcodec/tiffenc.c

[Michael Niedermayer]

Hi

On Wed, Apr 04, 2007 at 05:30:58PM +0200, Michel Bardiaux wrote:
> Uoti Urpala wrote:
> >On Wed, 2007-04-04 at 16:51 +0200, Michel Bardiaux wrote:
> >>Uoti Urpala wrote:
> >>>&s->width would be a pointer to int, which is wrong as a pointer to
> >>>uint32_t is needed.
> >>add_entry just needs void*.
> >
> >No it needs a pointer to a 4 byte int. The parameter type of the
> >function is void *, but there are semantic requirements beyond that.
> >void * doesn't mean you could pass it any random pointer whatsoever and
> >expect it to do something sensible.
> >
> Sometimes its a 2-bytes unsigned. But you're right, &s->width would not 
> work if sizeof(int)!=4. I suppose the way to go is:
> 
> uint32_t buf32;
> ...
> buf32 = s->width;
> add_entry(s, TIFF_WIDTH,TIFF_LONG,1,&buf32);
> 
> Which is awkward, which explains why C9x introduced the construct.

argh, i thought gcc 2.95 supports this, it does not :(
it only works if the array is dereferenced if its not (its address is used)
it fails

well how do we solve this
option A: make the entries in the struct match the correct uint* so we can
just take their address

option B:
add_entry1(..., i){
    uint32_t dw=i;
    uint16_t w=i;
    add_entry(..., 1, type == TIFF_SHORT ? &w : &dw);
}

i think B is cleaner, feel free to fix it like that

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20070405/363effe0/attachment.pgp>