[FFmpeg-devel] [PATCH] Enhance ffmpeg.c:opt_default()
Stefano Sabatini
stefano.sabatini-lala
Sat May 17 18:49:11 CEST 2008
On date Saturday 2008-05-17 17:04:02 +0200, Michael Niedermayer encoded:
> On Sat, May 17, 2008 at 04:38:26PM +0200, Stefano Sabatini wrote:
> > On date Saturday 2008-05-17 16:14:32 +0200, Michael Niedermayer encoded:
> > > On Sat, May 17, 2008 at 12:24:58PM +0200, Stefano Sabatini wrote:
> > > > On date Friday 2008-05-16 18:24:11 +0200, Michael Niedermayer encoded:
> > > > > On Fri, May 16, 2008 at 01:57:09AM +0200, Stefano Sabatini wrote:
> > [...]
> > > > > > Index: libavcodec/opt.c
> > [...]
> > > > > > -static const AVOption *av_set_number(void *obj, const char *name, double num, int den, int64_t intnum){
> > > > > > +static const AVOption *av_set_number2(void *obj, const char *name, double num, int den, int64_t intnum, const char **error_ptr){
> > > > > > const AVOption *o= av_find_opt(obj, name, NULL, 0, 0);
> > > > > > + static char error[128];
> > > > > > +
> > > > >
> > > > > rejected
> > > >
> > > > Well I know it sucks like a solution, what about to allocate the error
> > > > buffer and leave to the av_set_string2() user to free it?
> > >
> > > RTFS eval.c
> >
> > Yes, indeed I started from there, the difference is that while in
> > eval.c the error string is set to a statically allocated string, I
> > would like in this case to return an error message with a variable
> > content, e.g.:
> >
> > "The value for 'foo' was -1 which is not within 0 - inf\n";
>
> "The value for '%s' was %f which is not within %f - %f\n"
>
> still static const ...
Yes, but then you need to implement the logic to interpret the
parametric string outside av_set_number2(), which seems pretty nasty
to me.
So if I correctly understand what you mean I still continue to prefer
to allocate on the fly the error string, then demandate to the user
programmer to free it (or to memleaks if he so prefers), which is
still better than decode and fill the static const string.
BTW there is a similar problem in eval.c too (problem actually masked
by the presence of other bugs).
Regards.
--
FFmpeg = Freak & Funny MultiPurpose EnGraver
More information about the ffmpeg-devel
mailing list