[FFmpeg-devel] [PATCH] ffprobe: print non-time values like integer if they have no decimal part

[Stefano Sabatini]

On date Sunday 2011-11-06 15:02:57 +0100, Michael Niedermayer encoded:
> On Sun, Nov 06, 2011 at 02:07:10PM +0100, Stefano Sabatini wrote:
> > On date Monday 2011-10-24 04:10:31 +0200, Michael Niedermayer encoded:
> > > On Mon, Oct 24, 2011 at 02:40:02AM +0200, Stefano Sabatini wrote:
> > > > Prettify, simplify parsing for integer values.
> > > > ---
> > > >  ffprobe.c |   16 ++++++++++++----
> > > >  1 files changed, 12 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/ffprobe.c b/ffprobe.c
> > > > index 5913d60..c21c57c 100644
> > > > --- a/ffprobe.c
> > > > +++ b/ffprobe.c
> > > > @@ -90,11 +90,19 @@ static char *value_string(char *buf, int buf_size, double val, const char *unit)
> > > >              prefix_string = decimal_unit_prefixes[index];
> > > >          }
> > > >  
> > > > -        snprintf(buf, buf_size, "%.3f%s%s%s", val, prefix_string || show_value_unit ? " " : "",
> > > > -                 prefix_string, show_value_unit ? unit : "");
> > > > +        if (val != (int)val)
> > > 
> > > i think this can crash with nan/inf
> > 
> > According to C spec:
> > 
> > 6.3.1.4 Real floating and integer
> > 1 When a finite value of real floating type is converted to an integer type other than _Bool,
> >   the fractional part is discarded (i.e., the value is truncated toward zero). If the value of
> >   the integral part cannot be represented by the integer type, the behavior is undefined.
> 
> 1 undefined behavior
>   behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
>   for which this International Standard imposes no requirements
> 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable
>   results, to behaving during translation or program execution in a documented manner characteristic of the
>   environment (with or without the issuance of a diagnostic message), to terminating a translation or
>                                                                       ^^^^^^^^^^^^^^
>   execution (with the issuance of a diagnostic message).
>   ^^^^^^^^^

In practice the passed value is *always* convertible to an int (indeed
it is a size, or a bitrate, casted to double and casted back to int
here), and we have already other double-to-int casts in the same
function, so I'd rather avoid pointless checks.  In case of a non-int
int64_t value, this may need to be changed though.

Alternatively I could create a value_string_int() accepting int but
this looks overkill and unnecessary as far as it goes.
-- 
FFmpeg = Friendly and Fiendish Maxi Puristic Embarassing Game