[Solved] Error 2 error C4430: missing type specifier – int assumed. Note: C++ does not support default-int

Question

This is actually a rather interesting error; the error message doesn’t do much to tell you what the problem is.

My initial speculation was largely incorrect, but I’ve left it in place for now. See below.

This code:

#ifndef uint32_t
#define unsigned int    uint32_t;
#endif

is incorrect. The name of the macro being defined goes immediately after the #define, and a macro definition normally should not include a semicolon. (Macro definition syntax is quite different from declaration syntax.) Rather than defining uint32_t, this defines unsigned, and attempting to redefine a language keyword can cause serious problems. Also, the #ifndef is not useful, since the uint32_t, if it’s defined via "stdafx.h", is a typedef, not a macro. You can use #ifdef UINT32_MAX to check whether `uint32_t has been defined. A correct version is:

#ifndef UINT32_MAX
#define uint32_t unsigned int
#endif

or, even better:

#ifndef UINT32_MAX
typedef unsigned int uint32_t;
#endif

That needs to be fixed, but it didn’t cause the problem you’re seeing. Apparently uint32_t is not defined in your implementation, causing this declaration:

uint32_t    emp_id;

to fail.

The error message is still misleading. Since uint32_t has not been declared, it’s treated as an ordinary identifier, not as a type name — and type names are treated as syntactically distinct from ordinary identifiers. The compiler attempted to recover from the error by guessing that uint32_t might be a member name, which means it should be followed by a semicolon — but then the declaration

uint32_t;

would declare a member with no explicit type. In old versions of C, this would be legal and would make the member an int. The compiler’s guess about what the code actually meant was wrong.

Incidentally, if you show an error message, please tell us which line it applies to.

My initial speculation about the cause of the problem, which turned out to be incorrect follows. I had guessed that _TCHAR was a macro, but it’s actually a typedef.

The macro definition:

#ifndef uint32_t
#define unsigned int    uint32_t;
#endif

has several levels of wrongness. In a macro definition, the macro being defined goes first, followed by the sequence that it expands to — which usually should not be terminated by a semicolon:

#define uint32_t unsigned int

But using a macro for this purpose is a bad idea; a typedef is much better:

typedef unsigned int uint32_t;

(note that the identifier being defined goes last, and a semicolon is required; macro definitions and typedefs have very different syntax). And unlike macros, there’s no way to test whether a typedef has already been defined.

The uint32_t should already be defined in <stdint.h> or <cstdint> — but that’s a standard header that was added to C by the 1999 ISO C standard, and adopted in C++ only by the 2011 ISO C++ standard, so there’s a decent chance that it won’t be available, depending on what C++ implementation you’re using. If the header exists, you can use #ifdef UINT_MAX to determine whether uint32_t is defined, but that’s only useful if you’re concerned about systems that don’t have a 32-bit unsigned type at all.

But your code doesn’t even refer to uint32_t — so why did the macro definition cause a problem?

Because you got the order wrong, your macro definition doesn’t define uint32_t, it defines unsigned, so that any occurrence of that word will expand to int uint32_t; (including the semicolon).

But you don’t refer to unsigned either — at least not directly. The problem, then, is in your definition of _tmain:

int _tmain(int argc, _TCHAR* argv[])

Both _tmain as the program entry point and the type name _TCHAR are Microsoft-specific. I don’t have access to a Microsoft compiler at the moment, but judging by the error message you’re seeing, _TCHAR (which logically should be a typedef) is probably a macro that expands to something like unsigned short (using a 16-bit type because Windows likes to use 16-bit wide characters for UTF-16).

So your definition:

int _tmain(int argc, _TCHAR* argv[])

expands to:

int _tmain(int argc, unsigned short* argv[])

which, because you’ve unintentionally redefined unsigned, then expands to:

int _tmain(int argc,  int uint32_t; short* argv[])

And since parameter declarations are separated by commas, not by semicolons, this is a syntax error. I’m not sure why this leads to the particular error message you’re seeing, but it’s not terribly surprising. Syntax errors, particularly those involving incorrectly defined macros, often lead to confusing error messages.

The best strategy for something like this is usually to look at the earliest line on which the compiler reports an error. If the error message itself is not illuminating, ignore it and study the source, trying to figure out what you might have gotten wrong.

If that fails (as it would in this case), try running your program through just the preprocessor. Most Unix-based compilers, including gcc, use a -E option for this; I don’t know the corresponding option for Microsoft. The output of the preprocessor is likely to be very verbose (it will include mangled copies of all the headers you include, directly or indirectly), but examining it might lead you to something useful.

In this particular case, commenting out your #define directive would have made the error go away (CORRECTION: no, it wouldn’t), which would be a clue that there’s something wrong with the #define, even though the relationship between it and the error message is far from obvious.

Accepted Answer

This is actually a rather interesting error; the error message doesn’t do much to tell you what the problem is.

My initial speculation was largely incorrect, but I’ve left it in place for now. See below.

This code:

#ifndef uint32_t
#define unsigned int    uint32_t;
#endif

is incorrect. The name of the macro being defined goes immediately after the #define, and a macro definition normally should not include a semicolon. (Macro definition syntax is quite different from declaration syntax.) Rather than defining uint32_t, this defines unsigned, and attempting to redefine a language keyword can cause serious problems. Also, the #ifndef is not useful, since the uint32_t, if it’s defined via "stdafx.h", is a typedef, not a macro. You can use #ifdef UINT32_MAX to check whether `uint32_t has been defined. A correct version is:

#ifndef UINT32_MAX
#define uint32_t unsigned int
#endif

or, even better:

#ifndef UINT32_MAX
typedef unsigned int uint32_t;
#endif

That needs to be fixed, but it didn’t cause the problem you’re seeing. Apparently uint32_t is not defined in your implementation, causing this declaration:

uint32_t    emp_id;

to fail.

The error message is still misleading. Since uint32_t has not been declared, it’s treated as an ordinary identifier, not as a type name — and type names are treated as syntactically distinct from ordinary identifiers. The compiler attempted to recover from the error by guessing that uint32_t might be a member name, which means it should be followed by a semicolon — but then the declaration

uint32_t;

would declare a member with no explicit type. In old versions of C, this would be legal and would make the member an int. The compiler’s guess about what the code actually meant was wrong.

Incidentally, if you show an error message, please tell us which line it applies to.

My initial speculation about the cause of the problem, which turned out to be incorrect follows. I had guessed that _TCHAR was a macro, but it’s actually a typedef.

The macro definition:

#ifndef uint32_t
#define unsigned int    uint32_t;
#endif

has several levels of wrongness. In a macro definition, the macro being defined goes first, followed by the sequence that it expands to — which usually should not be terminated by a semicolon:

#define uint32_t unsigned int

But using a macro for this purpose is a bad idea; a typedef is much better:

typedef unsigned int uint32_t;

(note that the identifier being defined goes last, and a semicolon is required; macro definitions and typedefs have very different syntax). And unlike macros, there’s no way to test whether a typedef has already been defined.

The uint32_t should already be defined in <stdint.h> or <cstdint> — but that’s a standard header that was added to C by the 1999 ISO C standard, and adopted in C++ only by the 2011 ISO C++ standard, so there’s a decent chance that it won’t be available, depending on what C++ implementation you’re using. If the header exists, you can use #ifdef UINT_MAX to determine whether uint32_t is defined, but that’s only useful if you’re concerned about systems that don’t have a 32-bit unsigned type at all.

But your code doesn’t even refer to uint32_t — so why did the macro definition cause a problem?

Because you got the order wrong, your macro definition doesn’t define uint32_t, it defines unsigned, so that any occurrence of that word will expand to int uint32_t; (including the semicolon).

But you don’t refer to unsigned either — at least not directly. The problem, then, is in your definition of _tmain:

int _tmain(int argc, _TCHAR* argv[])

Both _tmain as the program entry point and the type name _TCHAR are Microsoft-specific. I don’t have access to a Microsoft compiler at the moment, but judging by the error message you’re seeing, _TCHAR (which logically should be a typedef) is probably a macro that expands to something like unsigned short (using a 16-bit type because Windows likes to use 16-bit wide characters for UTF-16).

So your definition:

int _tmain(int argc, _TCHAR* argv[])

expands to:

int _tmain(int argc, unsigned short* argv[])

which, because you’ve unintentionally redefined unsigned, then expands to:

int _tmain(int argc,  int uint32_t; short* argv[])

And since parameter declarations are separated by commas, not by semicolons, this is a syntax error. I’m not sure why this leads to the particular error message you’re seeing, but it’s not terribly surprising. Syntax errors, particularly those involving incorrectly defined macros, often lead to confusing error messages.

The best strategy for something like this is usually to look at the earliest line on which the compiler reports an error. If the error message itself is not illuminating, ignore it and study the source, trying to figure out what you might have gotten wrong.

If that fails (as it would in this case), try running your program through just the preprocessor. Most Unix-based compilers, including gcc, use a -E option for this; I don’t know the corresponding option for Microsoft. The output of the preprocessor is likely to be very verbose (it will include mangled copies of all the headers you include, directly or indirectly), but examining it might lead you to something useful.

In this particular case, commenting out your #define directive would have made the error go away (CORRECTION: no, it wouldn’t), which would be a clue that there’s something wrong with the #define, even though the relationship between it and the error message is far from obvious.