|
Clearing errors in GCC |
nshade
Member #4,372
February 2004
|
So I'm porting some legacy DOS code to Windows and I have the game compiling under Visual Studio with no errors or warnings. Over the weekend I ported the game to Linux, and I'm in the process of cleaning up the warnings that GCC is giving me. (It appears that it's a little more picky over warnings) I have GCC down to 10 warnings and I have two warning types left that I'm stuck on and don't quite know what the compiler is asking of me. The first warning: /* Compute need factor */ temp = EXP / 13; while (supply[temp] == -1) temp--; pref[temp] = 8; temp2 = temp - 1; while (temp2 >= 0) pref[temp2--] = 8 - (temp - temp2); //<--- Warning here temp2 = temp + 1; while (temp2 <= 7) pref[temp2++] = 8 - (temp2 - temp); //<---Warning here preftot = 0; temp2 = 0;
The other warning class I'm not understanding is this 1void IceptStar(FwgPtr f, SolPtr p)
2{
3 int angle;
4
5 f->pos.navlock = 1;
6 f->pos.locktype = 6;
7 f->pos.lockto = NULL;
8 if ((int)p == 1) { //<----Warning here
9 f->pos.lockx = Game->solar.x1;
10 f->pos.locky = Game->solar.y1;
11 f->pos.lockr = Game->solar.starradius;
12 }
13 else {
14 f->pos.lockx = Game->solar.x2;
15 f->pos.locky = Game->solar.y2;
16 f->pos.lockr = Game->solar.star2radius;
17 }
18//...etc
19}
I can kinda see why this is acting strange. p is a pointer to a struct called SolarStru, whcih holds the solar system data. I have no idea what that cast is doing. How does casting a pointer to an int give you an intelligible answer to work off of? I can see why the compiler is throwing the warning. What would be the original motivation to do this and how would I approach making it better? |
Audric
Member #907
January 2001
|
The second one : The warning is because SolPtr is a pointer of one size, while "int" has a different size. For example, you may be compiling on a 64bit architecture so pointers are 8 bytes long, while int is still 4 bytes long. |
Peter Hull
Member #1,136
March 2001
|
First one: while (temp2 >= 0) { pref[temp2] = 8 - (temp - temp2); temp2--; }
Second one:
|
Audric
Member #907
January 2001
|
About 1, it's not very intuitive because there are specific rules about operator precedence, but it's not a strict order of evaluation (associativity often gets mistaken for order of evaluation as well). The compiler/CPU can "reorder" computations if it's more efficient (or run the in parallel), as long as the rules are respected. For example in exp1 = exp2, both expressions are necessary before the assignment can be performed, but nothing forces exp2 to be evaluated entirely before the evaluation of exp1 begins. The issues are always when some terms have side effects : increment/decrement, assignment itself, and function evaluation. |
torhu
Member #2,727
September 2002
|
Using a for statement makes it clearer how the loop is controlled. for (temp2 = temp - 1; temp2 >= 0; temp2--) { pref[temp2] = 8 - (temp - temp2); }
|
|