[FFmpeg-devel] [PATCH] Implement the function cmdutils.c:parse_int_or_die
Wed Feb 20 18:14:43 CET 2008
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)
> minimum values of exact-width signed integer types
> exactly -(2^(N-1) )
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
More information about the ffmpeg-devel