[FFmpeg-devel] [PATCH] Implement the function cmdutils.c:parse_int_or_die
D. Hugh Redelmeier
Wed Feb 20 18:30:06 CET 2008
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
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
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. 188.8.131.52)
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.
More information about the ffmpeg-devel