[FFmpeg-devel] [PATCH] Implement the function cmdutils.c:parse_int_or_die

[Rich Felker]

On Wed, Feb 20, 2008 at 02:09:12PM +0100, Michael Niedermayer wrote:
> > | > Matter of taste: int64_t should only be used where the problem
> > | > dictates it.  long int or long long int are more abstract.  Of course
> > | > there is the problem that you don't know exactly what you are getting.
> > | > The C language really isn't very good in this area.  It is true that
> > | > long long can hold any int64_t value but the reverse may not be the
> > | > case.
> > | 
> > | This parses command line options and the range of valid values is not
> > | something which should depend on LLONG_MAX. Whatever the allowed range it
> > | should be allowed independant of LLONG_MAX.
> > 
> > Sure, but I claim that any values of type int or int64_t will of
> > necessity (by way of guarantees in the C standard) be within the range
> > [LLONG_MIN, LLONG_MAX].
> 
> That is not true. Quoting the C spec:
> --------
>  minimum value for an object of type long long int
>                     -9223372036854775807 // -(2^63 - 1)
>  LLONG_MIN
> --------
>  minimum values of exact-width signed integer types
>                                            exactly -(2^(N-1) )
>  INTN_MIN
> --------

Any ones-complement implementation is completely unusable by ffmpeg
and utterly irrelevant. *_MIN is always a negated exact power of two
on any usable machine.

> > | the != '\0' is also useless
> > 
> > I think that it makes the code a lot easier to read.
> 
> Peoples opinions differ. Ours is != 0 has to be removed.

Uhg, != '\0' is even uglier than != 0...

> > For example, see
> > the 7th bullet point of section 9 of this coding standard:
> >   http://www.chris-lott.org/resources/cstyle/indhill-annot.html

Irrelevant to the issue. Note that this is under a section on
portability which is completely off-topic to the issue of style.

> > See http://www.cs.uiowa.edu/~jones/syssoft/style.html#bool
> 
> spare me of these please

Hideous crap..

Rich