[Ffmpeg-devel] [PATCH] Partial port of ffmpeg to MS Visual C - and a note on the inttypes.h issue

[Yuri Vilmanis]

Dave Dodge wrote:
> On Thu, Jan 25, 2007 at 06:34:54PM +1030, Yuri Vilmanis wrote:
>   
>> Incidentally, FFMpeg uses the following C99 features which are marked as
>> broken or missing in gcc (see http://gcc.gnu.org/c99status.html) (these
>> I noted off-hand - there may be others):
>>     
> [...]
>   
>>  - extended integer types - stdint.h is marked missing, inttypes.h is
>> marked as having library issues (I gather this because it supplies the
>> typdefs which are meant to be in stdint.h - feel free to correct me here)
>>     
>
> This has to do with _extended_ integer types, which would be
> implementation-defined and wouldn't be used by any C99 code that was
> supposed to be at all portable.  I'm not sure why it says these are
> "missing" from stdint.h, since according to the 4.1.1 documentation
> gcc doesn't support any extended integer types in the first place and
> therefore there's nothing to be missed.
>
>                                                   -Dave Dodge
If you take a look at the C99 standard, you'll find under the library 
summary (Annex B) that inttypes.h (Section B.7) is for "Format 
conversion of integer types" and defines macros for integer type 
conversions. stdint.h (Section B.7) is for "Integer types", and includes 
all the type definitions for extended integers, including all types of 
the form uintN_t and intN_t.

 From Section 7.8 "Format conversion of integer types <inttypes.h>" 
paragraph 1:

"The header <inttypes.h> includes the header <stdint.h> and extends it 
with additional facilities provided by hosted implementations."

 From Section 7.18 "Integer types <stdint.h>" paragraphs 1 and 4:

"1 The header <stdint.h> declares sets of integer types having specified 
widths, and defines corresponding sets of macros. It also defines macros 
that specify limits of integer types corresponding to types defined in 
other standard headers."

"4 For each type described herein that the implementation provides,218) 
<stdint.h> shall declare that typedef name and define the associated 
macros. Conversely, for each type described herein that the 
implementation does not provide, <stdint.h> shall not declare that 
typedef name nor shall it define the associated macros. An 
implementation shall provide those types described as ??required??, but 
need not provide any of the others (described as ??optional??)."

and a little further on, in Section 7.18.1.1 "Exact-width integer 
types", paragraphs 1 through 3:

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

"2 The typedef name uintN_t designates an unsigned integer type with 
width N. Thus, uint24_t denotes an unsigned integer type with a width of 
exactly 24 bits."

"3 These types are optional. However, if an implementation provides 
integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and 
(for the signed types) that have a two?s complement representation, it 
shall define the corresponding typedef names."

Note that Section 7.18.1.1 is a subsection of Section 7.18, so we are 
still talking about stdint.h.

On the upside, as inttypes.h is required to include stdint.h, client 
code including only inttypes.h still works as it should - hence why its 
not a big deal to the gcc devs. On the other hand, just cos it works 
don't mean it meets the standard; the standard clearly specifies that 
these typedefs belong in stdint.h, which does not exist in gcc (and gcc 
would tell you so if you tried to #include <stdint.h>).

I hope this answers your ... statement?

Regards,
Yuri