[FFmpeg-devel] [PATCH] fix the SAMPLE_FMT_NONE case in ffmdec.c
Måns Rullgård
mans
Wed Mar 17 01:55:40 CET 2010
Bobby Bingham <uhmmmm at gmail.com> writes:
> On Wed, 17 Mar 2010 00:17:46 +0000
> M?ns Rullg?rd <mans at mansr.com> wrote:
>
>> Bobby Bingham <uhmmmm at gmail.com> writes:
>>
>> > On Tue, 16 Mar 2010 16:38:44 +0000
>> > M?ns Rullg?rd <mans at mansr.com> wrote:
>> > [...]
>> >> >> codec->sample_rate = get_be32(pb);
>> >> >> codec->channels = get_le16(pb);
>> >> >> codec->frame_size = get_le16(pb);
>> >> >> - codec->sample_fmt = get_le16(pb);
>> >> >> + codec->sample_fmt = sign_extend(get_le16(pb), 16);
>> >> >
>> >> > a simple cast to int16_t seems simpler
>> >>
>> >> Strictly speaking, that is undefined, but I don't think we care,
>> >
>> > Could you explain why is this undefined? My initial guess was that
>> > you're not guaranteed that signed integers two's complement,
>>
>> Correct.
>>
>> > but I thought you were guaranteed that for the fixed-width C99 int
>> > types.
>>
>> No, you're not. There are requirements on the range of values they
>> can hold, but no requirements on implementation.
>>
>
> From the copy of C99 TC2 I have:
>
> 1.18.1.1 Exact-width integer types
>
> The typedef name intN_t designates a signed integer type with width N ,
> no padding bits, and a two's complement representation. Thus, int8_t
> denotes a signed integer type with a width of exactly 8 bits.
My mistake. I forgot the exact-width types are special. My original
statement is still correct though: conversion to a signed type of a
value outside the range of that type is implementation-defined, even
for fixed-width types.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-devel
mailing list