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

[Dave Dodge]

On Thu, Feb 08, 2007 at 09:30:33PM +0200, Siarhei Siamashka wrote:
> On Thursday 08 February 2007 11:58, Baptiste Coudurier wrote:
> > > "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."
> >
> > Does that would mean we are using an optional feature ?

Technically, yes.

> So for example if by any chance you don't have int8_t defined, that
> would mean that the platform does not support 8-bit integer type at
> all and no other method will help you to solve this problem.

Right.  The only way those sizes will be missing from stdint.h is if
the implementation simply doesn't have a type of that size at all.
One way to lessen the impact of a missing intN_t is to use
int_leastN_t and int_fastN_t whenever possible, because those are
_always_ defined for 8, 16, 32, and 64.

Obviously if you really require an _exact_ integer size then you
should use intN_t to make that clear.  If the system doesn't have a
type of that size you simply can't expect to build your application
there.  Trying to fix it by for example defining int16_t yourself to a
type that isn't exactly 16 bits would just make things worse, and if
your code still worked when you did that then you really should have
been using int_least16_t or int_fast16_t in the first place.

There are definitely platforms that don't have all of 8, 16, 32, and
64-bit types, and you don't have to go back to the 1970's to find
them.  In the mid 90's I worked with a new Cray machine (running their
flavor of Unix) where char was 8 bits and the rest were all 64 bits.
I don't know if it was the same model, but I think at least one of the
major Cray designs couldn't address anything smaller than 64 bits at
the hardware level -- but for the sake of programmer sanity the ABI
and compiler simulated 8-bit bytes by using some high bits in a
pointer to keep track of which "byte" you were pointing at in a 64-bit
value.

I think there are current DSPs where the ABI has a 32- or 64-bit char,
but of course those aren't as likely to be running a general-purpose OS.

                                                  -Dave Dodge