C2084 FUNCTION ALREADY HAS A BODY
-
I just recompile that file seems like the compiler doesn't like function definition but there is nothing wrong with it. I don't have hex_to_acii anywhere in the file
void hex_to_ascii(BYTE *ipx, char *str, int num) <-- line 1607
{ <- line 1606
BYTE inst;
int i;
char *holdstr;and got this compile error message (1607): error C2084: function 'void hex_to_ascii(BYTE *,char *,int)' already has a body 1> d:\cpu.c(1606) : see previous definition of 'hex_to_ascii'
Haha if we have ruled out multiple includes let me guess at this ... ready You have a forward declaration prototype at line 43 >>> cpu.c(43):void hex_to_ascii(BYTE *ipx, char *str, int num); You have the body presented at line 1606 >>> cpu.c(1606): void hex_to_ascii(BYTE *ipx, char *str, int num) BYTE is a non standard and often misused piece of junk definition often abused by people. I am going to guess the definition of BYTE between line 43 and 1606 changes. So it's trying to tell you that you forward declared a prototype in that name already and your new body mismatches its definition and is trying to define under the same name. Usually the problem is BYTE gets defined as a char one place and as unsigned char somewhere else and so the compiler has two non matching definitions of BYTE. You just see the word BYTE but you can't see it's definition. In Visual studio if you right click on the word BYTE in both cases and on the menu click on "goto definition" it will show you what it is using for the two definitions. This is the reason the standards type unit was created to stop this sort of problem. If that is the problem the solution is simple #include and use the proper standard type uint8_t which is an unsigned 8 bit integer which is after all what the non standard BYTE definition is I imagine.
In vino veritas
-
ForNow wrote:
I don't have hex_to_acii anywhere in the file
...and then you proceed to show me how you have hex_to_ascii defined... :doh:
-
I meant just that one area I am not sure how make a namespace in C Besides from compiler message it seems like it doesn't like the way I declared the function in the file Maybe I'll rename it or move it to a different area in the file
Thought you were doing C++... in that case, change the name of the function and see if the error persists.
-
Hi I am getting the above error, and I know its a programmer trainee error but I can't for the life of me figure it out I did a find all from Visual Studio (looking in my solution directory) and what found was the function was defined once I did declare it ending with ';' And when I call it or the declaration or the actual routine all have the same parameter list Here is the result of the find all line 43 is the declaration line 1606 is the actual function line 1743 is where it actually used
, Subfolders, Find Results 1, "quot;"
cpu.c(43):void hex_to_ascii(BYTE *ipx, char *str, int num);
cpu.c(1606): void hex_to_ascii(BYTE *ipx, char *str, int num)
cpu.c(1743): hex_to_ascii(ipx,str,num);
hmacros.h(182): // extern void hex_to_ascii(BYTE *ipx, char *str, int num);
hmacros.h(187):// #define HEX_TO_ASCII(_ipx, _str, _num) / hex_to_ascii(_ipx ,_str, _num)
cpu.c(43) : see previous definition of 'hex_to_ascii'
Matching files: 3 Total files searched: 764 -
You have a definition of
hex_to_asciiin hmacros.h (defined asextern) and also in cpu.c. Remove the one from cpu.c and see if that fixes it.Assuming OP has cut'n'pasted accurately, the lines from
hmacros.hare commented out.Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Assuming OP has cut'n'pasted accurately, the lines from
hmacros.hare commented out.Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Assuming OP has cut'n'pasted accurately, the lines from
hmacros.hare commented out.Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
It won't be commented out nor does it need to be. I take it he is just using the commenting out to show whats there. Assuming it uncommented it's an extern (which is nothing more than a forward prototype) with a macro calling the extern. That won't create any problem at all as there is clearly no function body provided in hmacros.h by doing that and it will simply defer to the extern body provided with one big proviso that the prototype matches the external body declaration. I am still backing that BYTE gets defined differently (probably inside hmacros.h) and so the prototype doesn't match the body. We know BYTE must be defined prior to CPU.C using it and CPU.C then includes hamacros.h. I am betting hmacros.h defines BYTE as well (probably one is as a char and one as unsigned char). Given that the compiler is seeing no macro redefinition etc it's clear one will be #define BYTE ... and the other typedef so BYTE has two valid but different definitions which don't on their own clash. Here try it
typedef unsigned char BYTE;
void hex_to_ascii(BYTE *ipx, char *str, int num); // forward declaration#define BYTE char
void hex_to_ascii(BYTE *ipx, char *str, int num) {};
That is illegal in C especially if one is declared extern, the header and the body don't match because they are using different versions of BYTE. In C++ it would overload and then tell you one of your overloads hasn't got a body definition. Remove the macro and it will compile correctly because the forward declaration and body match then. It's dead easy to do and one of the normal problems of merging multiple libraries who like to make there own definitions.
In vino veritas
-
It won't be commented out nor does it need to be. I take it he is just using the commenting out to show whats there. Assuming it uncommented it's an extern (which is nothing more than a forward prototype) with a macro calling the extern. That won't create any problem at all as there is clearly no function body provided in hmacros.h by doing that and it will simply defer to the extern body provided with one big proviso that the prototype matches the external body declaration. I am still backing that BYTE gets defined differently (probably inside hmacros.h) and so the prototype doesn't match the body. We know BYTE must be defined prior to CPU.C using it and CPU.C then includes hamacros.h. I am betting hmacros.h defines BYTE as well (probably one is as a char and one as unsigned char). Given that the compiler is seeing no macro redefinition etc it's clear one will be #define BYTE ... and the other typedef so BYTE has two valid but different definitions which don't on their own clash. Here try it
typedef unsigned char BYTE;
void hex_to_ascii(BYTE *ipx, char *str, int num); // forward declaration#define BYTE char
void hex_to_ascii(BYTE *ipx, char *str, int num) {};
That is illegal in C especially if one is declared extern, the header and the body don't match because they are using different versions of BYTE. In C++ it would overload and then tell you one of your overloads hasn't got a body definition. Remove the macro and it will compile correctly because the forward declaration and body match then. It's dead easy to do and one of the normal problems of merging multiple libraries who like to make there own definitions.
In vino veritas
If BYTE is defined differently between the forward declaration and the definition, you certainly wouldn't get a "redefinition" error.
-
If BYTE is defined differently between the forward declaration and the definition, you certainly wouldn't get a "redefinition" error.
It's not the prototype and body that causes the problem it's the syntax to do it ... try it
#define BYTE char
#define BYTE unsigned char
// You will get warning 'BYTE': macro redefinition ON ANY C COMPILER THAT MEETS C87+ SPECYou also can't have two typedefs try that as well
typedef char BYTE
typedef unsigned char BYTE
// You will get error 'BYTE': type redefinition ON ANY C COMPILER THAT MEETS C87+ SPECYou also must have the typedef first and the macro second, try this reverse case and see what happens :-)
#define BYTE char
typedef unsigned char BYTE
// It will expand to typedef unsigned char char .... good luck with that getting thru compilerIt is very specific and very annoying and painful, but it is that order typedef followed sometime later by a macro. Hence I know the order that it must be in. Seen it and done it a number of times and it's really really annoying and makes you scratch your head.
In vino veritas
-
It's not the prototype and body that causes the problem it's the syntax to do it ... try it
#define BYTE char
#define BYTE unsigned char
// You will get warning 'BYTE': macro redefinition ON ANY C COMPILER THAT MEETS C87+ SPECYou also can't have two typedefs try that as well
typedef char BYTE
typedef unsigned char BYTE
// You will get error 'BYTE': type redefinition ON ANY C COMPILER THAT MEETS C87+ SPECYou also must have the typedef first and the macro second, try this reverse case and see what happens :-)
#define BYTE char
typedef unsigned char BYTE
// It will expand to typedef unsigned char char .... good luck with that getting thru compilerIt is very specific and very annoying and painful, but it is that order typedef followed sometime later by a macro. Hence I know the order that it must be in. Seen it and done it a number of times and it's really really annoying and makes you scratch your head.
In vino veritas
That gives you an error on the redefinition of the macro... has nothing to do with using it in a function prototype. If the definition of a macro was changed in between forward declaration and definition, you'd get a different error, such as "symbol not found" when you try to use it.
-
That gives you an error on the redefinition of the macro... has nothing to do with using it in a function prototype. If the definition of a macro was changed in between forward declaration and definition, you'd get a different error, such as "symbol not found" when you try to use it.
No you don't ... think about it and just rewrite what it expands to This is what you have
typedef unsigned char BYTE;
void hex_to_ascii(BYTE *ipx, char *str, int num); // forward declaration#define BYTE char
void hex_to_ascii(BYTE *ipx, char *str, int num) {};
Expanded removing BYTE and replacing the type that is in scope it becomes ... dead simple Remember the macro is in the preprocessor which is why it always expands like this, and why the second BYTE is gone by compile time. The first BYTE remains (it is prior to the macro definition), and I strike it out and changed it to it's proper type.
void hex_to_ascii( (BYTE) unsigned char *ipx, char *str, int num); // forward declaration
void hex_to_ascii(char *ipx, char *str, int num) {
};
Get it your forward prototype and function body no longer match. Depending on the C compiler it can see it as 1.) Two different functions with the same name .. THAT IS AN ERROR 2.) The same function with mismatched or redefined types ... THAT IS AN ERROR Which depends how good your compiler is and there is no standard answer to what it will say. It even depends if they are in the same files or not because the compiler is trying to guess what you are meaning to do. His example complicates it because he has an extern in a 3rd file which I think means the compiler doesn't have a clue whats going on it's got 3 prototypes probably only 2 matching. As I said you are arguing about something that is easy to test and I have seen many times when joining multiple libraries together.
In vino veritas