[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