[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