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

[Måns Rullgård]

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
> -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.

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. 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.

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
representations, however.

-- 
M?ns Rullg?rd
mans at mansr.com