[MPlayer-dev-eng] libvo2, 1st proposed spec

Arpi arpi at thot.banki.hu
Sun Nov 18 15:12:56 CET 2001


Hi,

> >static vo2_handle_t* new_handle()
> >{
> >    vo2_handle_t* h=malloc(sizeof(vo2_handle_t));
> >    if(!h) return NULL;
> >    h->priv=malloc(sizeof(priv_t));
> >    if(!h->priv){ free(h); return NULL; }
> >    memset(h->priv,0,sizeof(priv_t));
> >    h->info=&info;
> >    h->functions=&functions;
> >    h->surface=NULL;
> >    return h;
> >}
> >
> 
> I myself propose we change new_handle() to:
> 
> static vo2_handle_t* new_handle( priv_t *priv )
> {
>     vo2_handle_t* h=malloc(sizeof(vo2_handle_t));
>     if(!h) return NULL;
>     h->priv = priv;
>     h->info=&info;
>     h->functions=&functions;
>     h->surface=NULL;
>     return h;
> }
> 
> 
> since, priv_t might contain pointers etc a sizeof(priv_t) isn't 
> useful... and why memset it to 0 when perhaps some of it's members are 
> initialized in init() the very function who returns new_handle(...)?
> 
> //David Holm

I do NOT agree in this one.
1. yes, priv_t of course may contain pointers and so on, but why is it a
problem? they are filled by functions in teh driver or may not used.
2. memset to 0 help us finding bugs. maybe in some case something is not
initialized. if it's random, we get untraceable sig11's. if it's 0 we can
easily find it.
the other reason: if we extends it in the future, i mean adding new fields,
we can suspect it's 0 if driver doesn't support/use it. easier than
modifying all drivers all time we change something.
and yes, it will eat a few cpu cycles. but who cares here if it help us in
development or debugging.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu



More information about the MPlayer-dev-eng mailing list