[FFmpeg-devel] [PATCH] Implement the function cmdutils.c:parse_int_or_die
Wed Feb 20 19:12:00 CET 2008
D. Hugh Redelmeier wrote:
> 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
> two's complement.
C99 allows any of those three forms of signed integers.
> 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.
I don't see anything in the standard explicitly mandating two's complement
for these types, but it's probably the only possible implementation
consistent with the range requirements.
> (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.
The standard requires [u]intmax_t, which must be capable of representing
any value of any [unsigned] integer type.
There are also the [u]int_leastN_t types, which are required, even
the 64-bit versions. The ranges of these permit either of the sign
mans at mansr.com
More information about the ffmpeg-devel