[Ffmpeg-devel] stdint.h and inttypes.h for non-C99 compilers

[Alexander Chemeris]

On 12/13/06, Steve Lhomme <steve.lhomme at free.fr> wrote:
> Alexander Chemeris wrote:
> > On 12/13/06, Steve Lhomme <steve.lhomme at free.fr> wrote:
> >> @@ -42,6 +42,10 @@
> >>
> >>  #include <stdint.h>
> >>
> >> +#ifdef __cplusplus
> >> +extern "C" {
> >> +#endif
> >> +
> >>  // 7.8 Format conversion of integer types
> >>
> >>  typedef struct {
> >> @@ -268,7 +272,7 @@
> >>
> >>  // This is modified version of div() function from Microsoft's div.c
> >> found
> >>  // in %MSVC.NET%\crt\src\div.c
> >> -_inline imaxdiv_t __cdecl imaxdiv(intmax_t numer, intmax_t denom)
> >> +_inline imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom)
> >>  {
> >>     imaxdiv_t result;
> >>
> >> @@ -292,5 +296,8 @@
> >>  #define wcstoimax _wcstoi64
> >>  #define wcstoumax _wcstoui64
> >>
> >> +#ifdef __cplusplus
> >> +}
> >> +#endif
> >>
> >>  #endif // _MSC_INTTYPES_H_ ]
> > Why do you change this?
> > Is __cdecl is not enough?
>
>  From the MSDN "C functions and data can be accessed only if they are
> previously declared as having C linkage. However, they must be defined
> in a separately compiled translation unit.
>
> Microsoft C++ supports the strings "C" and "C++" in the string-literal
> field. All of the standard include files use the extern "C" syntax to
> allow the run-time library functions to be used in C++ programs.".
>
> I don't think it's nice to enforce the call method for an inline
> function, so in any case it should be removed.
And if it is static it is fine. In any case it does not hurt anybody. Let it be.
And for statc and inline functions this modifiers does not matter, yeah?

> >> @@ -47,14 +47,14 @@
> >>  // 7.18.1 Integer types
> >>
> >>  // 7.18.1.1 Exact-width integer types
> >> -typedef INT8    int8_t;
> >> -typedef INT16   int16_t;
> >> -typedef INT32   int32_t;  // There is LONG32 type defined the same.
> >> Should it be used here?
> >> -typedef INT64   int64_t;  // There is LONG64 type defined the same.
> >> Should it be used here?
> >> -typedef UINT8   uint8_t;
> >> -typedef UINT16  uint16_t;
> >> -typedef UINT32  uint32_t;  // There are ULONG32 and DWORD32 type
> >> defined the same. Should one of them be used here?
> >> -typedef UINT64  uint64_t;  // There are ULONG64 and DWORD64 type
> >> defined the same. Should one of them be used here?
> >> +typedef signed __int8   int8_t;
> >> +typedef signed __int16  int16_t;
> >> +typedef signed __int32  int32_t;  // There is LONG32 type defined the
> >> same. Should it be used here?
> >> +typedef signed __int64  int64_t;  // There is LONG64 type defined the
> >> same. Should it be used here?
> >> +typedef unsigned __int8  uint8_t;
> >> +typedef unsigned __int16 uint16_t;
> >> +typedef unsigned __int32 uint32_t;  // There are ULONG32 and DWORD32
> >> type defined the same. Should one of them be used here?
> >> +typedef unsigned __int64 uint64_t;  // There are ULONG64 and DWORD64
> >> type defined the same. Should one of them be used here?
> >>
> >>  // 7.18.1.2 Minimum-width integer types
> >>  typedef int8_t    int_least8_t;
> > I should test VC6 compatibility... If this will help - I commit it.
>
> As I said in a previous email I already tried it in VC6 and it worked
> fine. But 2 checks are better than one :)
I've checked VC6 documentation and includes and it should be fine.
I also looked through other defines and functions and looks like all off them
are supported. I'll write tests for this later may be.

-- 
Regards,
Alexander Chemeris.