carlevans719 / msinttypes Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/msinttypes
Automatically exported from code.google.com/p/msinttypes
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.
Original issue reported on code.google.com by [email protected]
on 15 Jul 2013 at 7:47
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).
Original issue reported on code.google.com by [email protected]
on 24 Aug 2009 at 3:52
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 5 Jan 2011 at 9:58
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)
Original issue reported on code.google.com by [email protected]
on 5 Aug 2010 at 6:28
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
Original issue reported on code.google.com by [email protected]
on 21 May 2008 at 12:47
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. :)
Original issue reported on code.google.com by [email protected]
on 6 Jun 2009 at 12:43
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.
Original issue reported on code.google.com by [email protected]
on 1 Dec 2010 at 9:48
Attachments:
Cosmetic change, see attached patch.
Original issue reported on code.google.com by [email protected]
on 19 Jan 2015 at 9:59
Attachments:
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).
Original issue reported on code.google.com by [email protected]
on 22 Jan 2009 at 9:07
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.
Original issue reported on code.google.com by [email protected]
on 15 Mar 2010 at 9:30
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
Original issue reported on code.google.com by [email protected]
on 22 Jan 2014 at 6:03
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
Original issue reported on code.google.com by [email protected]
on 20 Jan 2011 at 11:51
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).
Original issue reported on code.google.com by [email protected]
on 11 Mar 2010 at 6:43
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
Original issue reported on code.google.com by [email protected]
on 22 Jan 2014 at 5:54
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;
Original issue reported on code.google.com by [email protected]
on 28 Apr 2009 at 2:34
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.
Original issue reported on code.google.com by [email protected]
on 19 Jan 2015 at 10:03
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.