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

[D. Hugh Redelmeier]

From: Michael Niedermayer <michaelni at gmx.at>

On Wed, Feb 20, 2008 at 01:43:19PM -0000, M?ns Rullg?rd wrote:

> Michael Niedermayer wrote:
> > On Wed, Feb 20, 2008 at 01:51:22AM -0500, D. Hugh Redelmeier wrote:
> >> 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
> 
> You missed the part that says of these values:
> 
>   Their implementation-defined values shall be equal or greater in
>   magnitude (absolute value) to those shown, with the same sign.
> 
> It is perfectly legal for long long to be wider than 64 bits, but it
> must be at least 64 bits.

yes but it does not need to support
-9223372036854775808
while
int64_t must support it

You are quite right.  I had forgotten this.

The C standard has traditionally allowed signed binary numbers to be
in one's or two's complement or sign magnitude form.  Reluctantly:
almost everyone used two's complement and a lot of real C code assumes
two's complement.

When <stdint.h> was added, an implementation was allowed (not
required) to define exact-width integer types.  For those types, the
standard mandates two's complement.  The expectation is that if a
system does not use two's complement it would not define these types.

(To be more accurate, I should point out that a C99 implementation that
uses two's complement, without padding, for integral types, and has
integral types of 8, 16, 32, or 64 bits, must define the corresponding
intN_t and uintN_t typedef names. 7.18.1.1)

If you assume that int64_t exists (as ffmpeg does) then I think that
you are safe in assuming that the machine uses two's complement and
thus long long can hold any int64_t value.