dreamway / msinttypes Goto Github PK

What steps will reproduce the problem?
1. Setup a new Win32 SmartDevice project in Visual Studio 2008
2. Add to the headers path the stdint.h file
3. Compile

What is the expected output? What do you see instead?
No compiler issues are expected, instead this errors pops up:
Error   1   error C2733: second C linkage of overloaded function 'wmemchr'
not allowed C:\Programmi\Windows Mobile 6
SDK\PocketPC\include\ARMV4I\wchar.h 115 HAL
Error   2   error C2733: second C linkage of overloaded function 'wcschr' not
allowed C:\Programmi\Windows Mobile 6
SDK\PocketPC\include\ARMV4I\wchar.h 117 HAL
Error   3   error C2733: second C linkage of overloaded function 'wcspbrk'
not allowed C:\Programmi\Windows Mobile 6
SDK\PocketPC\include\ARMV4I\wchar.h 119 HAL
Error   4   error C2733: second C linkage of overloaded function 'wcsrchr'
not allowed C:\Programmi\Windows Mobile 6
SDK\PocketPC\include\ARMV4I\wchar.h 121 HAL
Error   5   error C2733: second C linkage of overloaded function 'wcsstr' not
allowed C:\Programmi\Windows Mobile 6
SDK\PocketPC\include\ARMV4I\wchar.h 123 HAL

What version of the product are you using? On what operating system?
I'm using the r21 of the stdint.h.

Please provide any additional information below.
For what i've seen the issue is in the first few lines of the header.
The extern clause for the include of the wchar.h should be in place even if
the compiler version (_MSC_VER) is more than 1300 (in my case is 1500).

When the msinttypes directory is not in the project include paths list, a
build error is thrown from inttypes.h attempting to include stdint.h.

Steps to reproduce:
1. In Visual Studio, create a new empty C++ project.
2. Place the msinttypes files in the directory "<PROJECT DIR>/msinttypes".
3. Add the attached Main.cpp file to the project.
4. Attempt to build.

Realized output:
Build error: "fatal error C1083: Cannot open include file: 'stdint.h': No
such file or directory"

Expected output:
Project should build successfully.

Fix:
In inttypes.h, #include "stdint.h" rather than #include <stdint.h> (i.e.
use quotes rather than square brackets).

I think "fast" types are supposed to allow fast operations (basically, 
efficiently use the registers) on the target machines.

Example: int_fast16_t is currently defined as 16-bit integer, which is slow 
on modern machines. It should definitely map to the same type as 
int_fast32_t.

My gut feeling is that even int_fast32_t should map to a 64-bit integer on a 
64-bit platform (gcc/glibc do that, for example), but Visual Studio 10 
headers define that as "int" (which, if I recall correctly, is 32-bit long on 
Windows).

What steps will reproduce the problem?
1.
Thise defnitions will produce incorect results for Embedded Visual C++ 4
Sp4 on WCE420
typedef __int16           int16_t;
typedef unsigned __int16  uint16_t;

They are correct however short != __int16 for evc4 compiler for some
unknown reason and evc4 with STLPort produces for example:

std::numeric_limits<short>::max() == 65535
std::numeric_limits<__int16>::max() == 0

Beter relay of that what is defined in types.h

For example frm 

evc4 ARM
typedef signed      char        INT8;
typedef unsigned    char        UINT8;
typedef signed      short       INT16;
typedef unsigned    short       UINT16;
typedef signed      int         INT32;
typedef unsigned    int         UINT32;
typedef signed      __int64     INT64;
typedef unsigned    __int64     UINT64;

this code is invalid:

#ifdef __cplusplus
extern "C" {
#endif
#  include <wchar.h>
#ifdef __cplusplus
}
#endif

with some versions of sdk (or mobile sdk/WinCE) it produces errors. I'm pretty 
sure that this code was added because of buggy ffmpeg headers that still does 
not want to recognize that C headers can be used from c++. For this reason 
people incorrectly do this kind of mess:

extern "C"
{
#include <libavcoded/avcodec.h>
}

bug ffmpeg headers include lots of standard headers. Try to include them in 
your own code inside extern "C" and you'll get lots of problems.

So, that hack by including stdlib.h as extern C is a bug and should be removed.

To properly include ffmpeg headers in c++ all standard headers that ffmpeg 
pulls in should be include before ffmpeg headers, this way there won't be any 
issues and no need for this kludge in stdint.h

how about:

#include <../include/stdint.h>

then you could add msinttypes to include path and include stdint.h using:
#include <stdint.h>

Could you also check for presence of inttypes.h in different versions of VS and 
add proper ifdefs. vs2013 has inttypes.h

What steps will reproduce the problem?
--------------------------------------
Trying to compile the small program
#include "SDL.h"
extern "C"
{
#include "libavformat/avformat.h"
#include "libavcodec/avcodec.h"
#include "libavutil/avutil.h"
}

void main(void)
{
  return;
}


What is the expected output? 
----------------------------
An object file.

What do you see instead?
------------------------
Compiler error about redefinition of uint8t.

What version of the product are you using? On what operating system?
--------------------------------------------------------------------
MSVC2005
ffmpeg r 13018
SDL 1.2.13, prebuilt binaries and development files, downloaded from 
http://www.libsdl.org
Windows XP

Please provide any additional information below.
------------------------------------------------
I suggest adding 'signed' to type definitions in stdint.h on lines 59-62

In line 45 of file stdint.h we see:

// For Visual Studio 6 in C++ mode and for many Visual Studio versions when
// compiling for ARM we should wrap <wchar.h> include with 'extern "C++" {}'
// or compiler give many errors like this:
//   error C2733: second C linkage of overloaded function 'wmemchr' not allowed
#ifdef __cplusplus
extern "C" {

Well then, why 'extern "C"' and not 'extern "C++"' then?

An attempt to compile in fact produces exactly the errors mentioned above.
Could you fix it please, it should not be difficult :P

What steps will reproduce the problem?
1. Compile program requiring int8_t using /J
2. ???
3. Profit!

What is the expected output? What do you see instead?
The expected output would be int8_t remaining signed while the specific
"char" type would become unsigned.  This is the behavior of gcc with the
-funsigned-char parameter, which is equivalent to /J.

It looks like the C99 standard specifies that int8_t should always be
signed, so this bug applies to this specific project's header and not
MSVC's __int8 as MSVC is of course not C99 compliant.

The fix is of course the simple matter of altering the 2 lines of stdint.h
in question. :)

I think that your license headers in the stdint.h and inttypes.h files may
not say what you want them to say.

http://msinttypes.googlecode.com/svn/trunk/stdint.h
http://msinttypes.googlecode.com/svn/trunk/inttypes.h

Specifically, they currently say:

//   3. The name of the author may be used to endorse or promote products
//      derived from this software without specific prior written permission.

Perhaps you meant to say "may not be used" instead of "may be used" ?  Or
just use an updated version of the BSD license.

The stdint header that ships with Visual Studio 2010+ defines int_fast16_t and 
uint_fast16_t as 32-bit integer's, not 16.

I believe the standard only specifies that the fast types be at least the 
specified width.

See attached patch.

According to ISO/IEC 9899:TC3 7.18.2.2,

"Each instance of [INTn_MIN and INTn_MAX] shall be replaced by a constant 
expansion suitable for use in #if preprocessor directives, and this expression 
shall have the same type as would an expression that is an object of the 
corresponding type converted according to the integer promotions"

The INTn_MAX macros always violated the second requirement, and r19 means that 
the INTn_MIN macros now violate both requirements.

The recommended solution would be to define the INTn_MIN / INTn_MAX macros as 
follows:

#define INT8_MIN     (_I8_MIN + 0)
#define INT8_MAX     (_I8_MAX + 0)
#define INT16_MIN    (_I16_MIN + 0)
#define INT16_MAX    (_I16_MAX + 0)
#define INT32_MIN    (_I32_MIN + 0)
#define INT32_MAX    (_I32_MAX + 0)
#define INT64_MIN    (_I64_MIN + 0)
#define INT64_MAX    (_I64_MAX + 0)
#define UINT8_MAX    (_UI8_MAX + 0)
#define UINT16_MAX   (_UI16_MAX + 0)
#define UINT32_MAX   (_UI32_MAX + 0)
#define UINT64_MAX   (_UI64_MAX + 0)

What steps will reproduce the problem?
1. add inttypes.h and stdint.h with include files of ffmpeg
2. build code
3. the compilation gives error
F:\Windows 
Project\zeranoe\ffmpeg-20130713-git-aac57c7-win32-dev\include\inttypes.h(49): 
error C2146: syntax error : missing ';' before identifier 'quot'

What is the expected output? What do you see instead?
should compile like previous release (specifically tested r26) of msinttypes

What version of the product are you using? On what operating system?
r29 of msinttypes, Visual Studio 2012

Please provide any additional information below.
There are 3 lines in stdint.h

#if _MSC_VER >= 1600 // [
#include <stdint.h>
#else // ] _MSC_VER >= 1600 [

These 3 lines are responsible for the error. I have not found stdint.h with VS 
2012. To solve the issue I had temporarily replace it like this

#if _MSC_VER >= 1800 // [
#include <stdint.h>
#else // ] _MSC_VER >= 1800 [

I would like to know how the authors retained stdint.h with Visual Studio 2012.

Cosmetic change, see attached patch.

What steps will reproduce the problem?

1. #include <boost/cstdint.hpp> from boost 1.45 before #include <stdint.h>

What is the expected output? What do you see instead?
I see the following warning for INTMAX_C and for UINTMAX_C
{{{
D:\include\stdint.h(241) : warning C4005: 'INTMAX_C' : macro redefinition 
d:\include\boost1-45-0\boost/cstdint.hpp(423) : see previous definition of 
'INTMAX_C'
}}}

What version of the product are you using? On what operating system?
I am using Microsoft Visual C++ 2008 Express on Windows 7 64bits

The fix is very easy :
{{{
in stdint.h line 239:
// 7.18.4.2 Macros for greatest-width integer constants
#ifndef INTMAX_C //   [
#   define INTMAX_C   INT64_C
#endif // INTMAX_C    ]
#ifndef UINTMAX_C //  [
#   define UINTMAX_C  UINT64_C
#endif // UINTMAX_C   ]
}}}

In attachment, a patch file with this modifications.
Best regards,
Nicolas.

Steps to reproduce:
In Visual Studio 2010, create an application that includes stdint.h from 
msinttypes as well as the compiler's included stdint.h.

Attempt to build it. You will receive several compiler warnings about 
redefinition of macros, typedefs, etc.

Solution:
Within stdint.h, if the compiler provides its own stdint.h, include the 
compiler's version rather than manually defining everything, e.g...

#ifndef _MSC_VER // [
#error "Use this header only with Microsoft Visual C++ compilers!"
#endif // _MSC_VER ]

#ifndef _MSC_STDINT_H_ // [
#define _MSC_STDINT_H_

#if _MSC_VER > 1000
#pragma once
#endif

#if _MSC_VER >= 1600

#include <stdint.h>

#else

// ...remainder of file...

#endif