#15787 - slboytoy - Fri Jan 30, 2004 6:24 am
When I call another function within a function it gives me a warning..
| Quote: |
Type mismatch with previous implicit declaration
Previous implicit declaration of 'ClearScreen'
'ClearScreen' was previously implicitly decalared to return 'int'
|
| Code: |
int MoveMemorySpot(int offset, int MemoryEnd, int Mem_Length)
{
if(!(*KEYS & KEY_RIGHT))
{
offset++;
if (offset > (MemoryEnd - Mem_Length + 3))
offset = MemoryEnd - Mem_Length + 3;
ClearScreen();
|
I know it's just a warning, and it still works fine, but its very annoying...
#15788 - tepples - Fri Jan 30, 2004 7:11 am
It means that you need ClearScreen()'s prototype in scope before you call ClearScreen().
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15799 - Paul Shirley - Fri Jan 30, 2004 3:54 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:15 pm; edited 1 time in total
#15804 - slboytoy - Fri Jan 30, 2004 6:04 pm
I have this defined in main.c
| Code: |
| void ClearScreen(void); |
Where the actually function is written is in display.c (which C includes)
Most of my functions don't come up with that warning, but then there are a few functions that the warning comes up...
So where should I be defining ClearScreen then?
#15805 - poslundc - Fri Jan 30, 2004 6:53 pm
1. Never, ever, ever #include a .c file. Only ever include header files (.h). These header files should only have things like #defines, typedefs, struct declarations, and prototypes. They should never contain any actual, executable C functions or global variables.
2. For every .c file in your project, have a corresponding .h file. In this .h file, put the function prototypes for any functions in its corresponding .c file that you want other .c files to be able to access. (eg. if display.c has the ClearScreen function and you want main.c to be able to call it, you would put the ClearScreen prototype in display.h.)
3. #include this header file in any .c files that need to call the functions in the header file's corresponding .c file.
Dan.
#15806 - Paul Shirley - Fri Jan 30, 2004 7:01 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:16 pm; edited 1 time in total
#15807 - Miked0801 - Fri Jan 30, 2004 7:16 pm
lmao. But my compiler/linker should be smart enough not to double/triple define things and not setup jumps to NULL and stuff right? ;)
#15811 - Paul Shirley - Fri Jan 30, 2004 8:13 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:16 pm; edited 1 time in total
#15812 - tepples - Fri Jan 30, 2004 8:30 pm
Or you can just use gcc -Wall to make the C compiler check prototypes and handle several other common errors.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15815 - Miked0801 - Fri Jan 30, 2004 10:03 pm
Sorry, my sarcasm was lost on that post. I'm well aware of what C will allow you to do if you aren't careful as over time I'm sure I've done most of them myself. Learn to love -Wall. Here's a snapshot of typical beginner C badness. See if how it takes you to find Waldo. :)
| Code: |
int dontTryThisAtHome(int *a, int *b, int count)
{
int i;
int equalCount;
for(i=0; i<count; i++);
{
if(a[i] = b[i])
{
equalCount++;
}
}
return equalCount;
}
|
#15816 - picomontoya - Fri Jan 30, 2004 11:20 pm
I think I found Waldo. Equal count is not initialized. And there is no error checking for the two pointer parameters. And the assignment operator is used not the equality operator. And there is a semicolon after the for statement's close-paranthesis. Did I miss something?
I like little games like this. Thank you, Miked0801.
_________________
www.familyradio.com
#15819 - dagamer34 - Sat Jan 31, 2004 4:35 am
Waldo(s)...
_________________
Little kids and Playstation 2's don't mix. :(
#15823 - Miked0801 - Sat Jan 31, 2004 6:30 am
| Quote: |
Did I miss something?
|
One more to find that is the nastiest of all - probably would cause the program to page fault at best and crash a winbox at worst :)
I'll give you a hint: it's part of something you already mentioned.
I'll post tomorrow :)
#15824 - tepples - Sat Jan 31, 2004 6:41 am
It does write to the location right after the end of the given range of a[].
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15826 - jd - Sat Jan 31, 2004 7:22 am
| tepples wrote: |
| It does write to the location right after the end of the given range of a[]. |
..and an illegal read right after the given range of b[]. (Both due to that pesky semicolon at the end the 'for' statement.)
#15827 - picomontoya - Sat Jan 31, 2004 9:57 am
Aw, rats. I wanted an A+.
_________________
www.familyradio.com
#15832 - Miked0801 - Sat Jan 31, 2004 6:20 pm
:) They found it.
And those are the kinds of bugs the -Wall will catch. I love it when people tell me "It's only a warning." The worst part is, this little bug would probably go un-noticed for a while on a GBA - causing some other function to act a bit screwy.
I really wish they'd put a "Warning: For Statement has semi-colon followed by open braces." into GCC to catch this. I got burned by that for the first time in years last week. I looked on the GCC site to see if there was a place to give suggestions, but couldn't find one.
As people seemed to enjoy that bug hunt, I'll make a new thread and post another one later. The sad part is at one of my job interviews, a similar problem was on the employee test :P
#15833 - Paul Shirley - Sat Jan 31, 2004 7:26 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:16 pm; edited 1 time in total
#15837 - tepples - Sun Feb 01, 2004 1:20 am
But -Wall does enable -Wimplicit-function-declaration, which does much the same thing, "[g]iv[ing] a warning (or error) whenever a function is used before being declared."
(For those playing at home, here's a list of warnings enabled and not enabled by gcc -Wall.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15850 - slboytoy - Sun Feb 01, 2004 6:01 pm
So in my Main.c I should have...
| Code: |
| include "display.h" |
and in my display.h i should have....
| Code: |
| void clearscreen(void); |
and in my display.c i should have...
| Code: |
void ClearScreen(void) // clear screen, and draw a blue back ground
{
int x,y;
for(x = 22; x<118;x++) //loop through all x
for(y = 40; y < 157; y++) //loop through all y
VideoBuffer[x+y*120] = RGB16(5,10,13);
}
|
What should my make file look like then?
#15851 - Paul Shirley - Sun Feb 01, 2004 6:40 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:17 pm; edited 1 time in total
#15852 - slboytoy - Sun Feb 01, 2004 6:53 pm
My make file looks like...
| Code: |
gcc -c -O3 -mthumb -mthumb-interwork main.c
gcc -c -O3 -mthumb -mthumb-interwork display.c
gcc -mthumb -mthumb-interwork -o main.elf main.o display.o
objcopy -O binary main.elf main.mb
|
But both main.c and display.c need the GBA.H file in order to compile, and then I get a redefinion error.
#15854 - Paul Shirley - Sun Feb 01, 2004 8:22 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:17 pm; edited 1 time in total
#15860 - slboytoy - Sun Feb 01, 2004 8:58 pm
Sorry I meant to say, within the header, I define a variable.
| Code: |
#ifndef KEYPAD_H
#define KEYPAD_H
//Key Definitions from Nokturn's key demo
#define KEY_A 1
#define KEY_B 2
#define KEY_SELECT 4
#define KEY_START 8
#define KEY_RIGHT 16
#define KEY_LEFT 32
#define KEY_UP 64
#define KEY_DOWN 128
#define KEY_R 256
#define KEY_L 512
int* KEYS = (int*)0x04000130;
#endif
|
Now if I need this header with two different C files, I get the error about KEYS being redefined. I tried putting 'static' infront of it, but then my keypad doesn't work at all...
How can I just call that header once, so the whole program can share it's resources. Or would I just put "KEYS" as a global variable?
#15862 - Paul Shirley - Sun Feb 01, 2004 9:52 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:17 pm; edited 1 time in total
#15863 - Miked0801 - Sun Feb 01, 2004 9:52 pm
Your KEYS declaration is creating memory and therefore shouldn't be located in an include file. Either #Define it, or put it in keypad.c and 'extern' it for use elsewhere. If you do the extern approach, I'd also declare it 'const' such that if something decides to change it, you'll get a warning.
Style-wise, I'd also declare the key definitions in Hex as they are always going to be used in bitwise operator/mask situations, but that's just me :)
#15870 - slboytoy - Mon Feb 02, 2004 1:20 am
After a lot of playing around, I think i've got it working. The best way to learn is to do, and try again. (many many times). ANd now it's time for football. thank guys.
#15874 - FluBBa - Mon Feb 02, 2004 9:42 am
And while we are at it, remember to read the Joypad reg only once every frame to get rid of bouncing and put it in a variable that you use later in the program, you can also have 2 or 3 variables so you can have Status/Pushed/Released.
_________________
I probably suck, my not is a programmer.