06 Feb, 2009, Igabod wrote in the 1st comment:
Votes: 0
Ok, my code was working fine till I decided to change the name of one of my newer files from iggytest.c to iggystuff.c. I removed all the object files and went to do a compile and got this message:

–>  Compiling file: act_comm.c  <–
In file included from act_comm.c:33:
merc.h:2806: error: array type has incomplete element type
make: *** [obj/act_comm.o] Error 1


line 2806 in merc.h is as follows

extern  const   struct  spec_type       spec_table      [];


I didn't change this at all though so I am confused here. Any help is appreciated.
06 Feb, 2009, Rojan QDel wrote in the 2nd comment:
Votes: 0
Did you update your Makefile to include iggystuff.c and remove iggytest.c?
06 Feb, 2009, Igabod wrote in the 3rd comment:
Votes: 0
My makefile uses wildcards so I don't need to edit the makefile every time I add a new file. If you wanna see my makefile I'll post it here though.
06 Feb, 2009, Rojan QDel wrote in the 4th comment:
Votes: 0
Nevermind, I'm just not very familiar with godwars!

You did make clean, then make?

Also, where is spec_table defined?
06 Feb, 2009, Igabod wrote in the 5th comment:
Votes: 0
make clean is removing the obj files and making so yes. That line I posted is the only line in the entire code containing "spec_table".
06 Feb, 2009, Sharmair wrote in the 6th comment:
Votes: 0
I don't know why what you describe doing would trigger this error, but what it would mean for
the line you give is that the definition for struct spec_type has not been seen yet. Make sure
the definition for struct spec_type is before this line.
06 Feb, 2009, David Haley wrote in the 7th comment:
Votes: 0
If you have an extern declaration, but no actual declaration, how is it supposed to work? Extern just means that "somewhere" the symbol has memory allocated, but unless you actually allocate that memory, well, the linker will fail to find anything…
06 Feb, 2009, Igabod wrote in the 8th comment:
Votes: 0
this is also the only line containing spec_type in the entire code.
06 Feb, 2009, Igabod wrote in the 9th comment:
Votes: 0
DavidHaley said:
If you have an extern declaration, but no actual declaration, how is it supposed to work? Extern just means that "somewhere" the symbol has memory allocated, but unless you actually allocate that memory, well, the linker will fail to find anything…


What can I say? I have never once even touched this line of the code before. It is how it was in stock.
06 Feb, 2009, Sharmair wrote in the 10th comment:
Votes: 0
Igabod said:
make clean is removing the obj files and making so yes. That line I posted is the only line in the entire code containing "spec_table".

The line is saying there is an array (of unspecified size) someplace else, so, if there is no someplace else,
it would mean something was removed (or never fully coded) and can just as well be removed.
06 Feb, 2009, David Haley wrote in the 11th comment:
Votes: 0
It's not so much a question of the line of code that was already there, as it is of the line(s) of code that were removed…
06 Feb, 2009, Igabod wrote in the 12th comment:
Votes: 0
well considering I did a clean compile just before I changed the name of iggytest.c to iggystuff.c and had no errors and made absolutely no other changes, that doesn't seem to fit. This is why the subject line calls it a "weird" error.
06 Feb, 2009, Igabod wrote in the 13th comment:
Votes: 0
ok now I'm starting to think my entire code is corrupted, I got this after commenting out line 2806 of merc.h

–>  Compiling file: act_comm.c  <–
[- act_comm.c compiled OK -]
–> Compiling file: act_info.c <–
act_info.c: In function âdo_diagnoseâ: <—————————supposed to be do_diagnose but it's adding an accented a to both ends.
act_info.c:4233: warning: the address of âargâ will never be NULL <————— arg with accented a on both ends
[- act_info.c compiled OK -]
–> Compiling file: act_move.c <–
act_move.c: In function âdo_trainâ: <——————————supposed to be do_train but it's adding an accented a to both ends.
act_move.c:2710: error: lvalue required as left operand of assignment
act_move.c:2717: warning: assignment from incompatible pointer type
act_move.c:2725: warning: assignment from incompatible pointer type
make: *** [obj/act_move.o] Error 1
06 Feb, 2009, Igabod wrote in the 14th comment:
Votes: 0
Ok so this is a problem with my server. The exact same code on my computer compiles fine with no errors. My host just recently upgraded to Debian Lenny and this is the first time I've compiled the code on there. The previous compile was done on my computer not on my server. My mistake. Regardless I'm not able to compile on my server and when I comment out that line it gives me the above problems. Any suggestions?
06 Feb, 2009, Sharmair wrote in the 15th comment:
Votes: 0
The new compiler might just be more picky about things. I have noticed funny characters in some
of the pastes from other compiler output here, so for now, I will just ignore those and look at the
warnings and errors. Commenting out that line got you past the first file and the warning in act_info.c
I have seen in some other code (issuing no warning BTW, again pointing to a more picky compiler).
More on that warning, I have seen in some code the coder checking for the NULLness of an array
name, maybe just doing the same checks you might do on a pointer. As an array name is NEVER
NULL the warning is real, though like I said, not issued in most compilers (at least in the past, frankly
I like the more picky compilers). You can just take out that part of the if check it is probably used in.
The next thing I really would look at is the next error you have that stopped the compile, that would
be 2710 in act_move.c. For now you just might want to work on the errors and leave the warning
until later, but you will just have to work through them, and we are here to help.
06 Feb, 2009, Igabod wrote in the 16th comment:
Votes: 0
Ok here's line 2710 in act_move.c with it's surrounding lines. It's in do_train.

else if ( !str_cmp( arg1, "hp") && ch->max_hit < hpcap)
{
if ( ch->max_hit < 1 ) ch->max_hit = 1; /* Bug fix */
cost = 2 * (ch->max_hit - ch->pcdata->perm_con);

(int *) pAbility = &ch->max_hit; <———- Line 2710
pOutput = "hp";
}


I was previously getting some warnings about lvalue being deprecated on my computer. I've been meaning to get around to this but never did. Now I have to since it's an error not a warning now.
06 Feb, 2009, Sharmair wrote in the 17th comment:
Votes: 0
Igabod said:
Ok here's line 2710 in act_move.c with it's surrounding lines. It's in do_train.

else if ( !str_cmp( arg1, "hp") && ch->max_hit < hpcap)
{
if ( ch->max_hit < 1 ) ch->max_hit = 1; /* Bug fix */
cost = 2 * (ch->max_hit - ch->pcdata->perm_con);

(int *) pAbility = &ch->max_hit; <———- Line 2710
pOutput = "hp";
}


I was previously getting some warnings about lvalue being deprecated on my computer. I've been meaning to get around to this but never did. Now I have to since it's an error not a warning now.

Yea, that cast (the (int *) before pAbility) is wrong. I am not sure form the code you give what types
pAbility and ch->max_hit are. They both should be the same type though. I take it this code sets pAbility
to the address of what ever is being trained, so once you fix this one line, you probably will get an
error on the next section of code, so you might as well look ahead and fix all the lines like this).
If some of the things you set pAbility to are different types (probably sh_int and int) you might want
to have two pointers, one for each type and set them to NULL to start, then set the proper one that
matches the data in each section, then at the end use the pointer that is not NULL to add the points
to. Something like (assumingthe two pointers pIntAbil and pSrtAbil):
if(pIntAbil)
*pIntAbil += 1;
else if(pSrtAbil)
*pSrtAbil += 1;

Note that if either pSrtAbil or pIntAbil is always set in one of the sections (it never gets here
with one or the other not set) you can leave the else out. At the top of the function where
pAbility is now, you would have:
sh_int* pSrtAbil = NULL;
int* pIntAbil = NULL;

And you would use one of these two instead of pAbility, the one that matches the data you are
setting it to point at. You could of coarse use pAbility (the name) for whatever type it is now.
Anyway, I really hope I have not confused this for you, if so just ask away.
06 Feb, 2009, Igabod wrote in the 18th comment:
Votes: 0
Yeah that was a little confusing… Even after reading it 2 more times. But here is the warning I get on my computer for that file, maybe this will help a little.
–>  Compiling file: act_move.c  <–
act_move.c: In function `do_train':
act_move.c:2710: warning: use of cast expressions as lvalues is deprecated
act_move.c:2717: warning: assignment from incompatible pointer type
act_move.c:2725: warning: assignment from incompatible pointer type
[- act_move.c compiled OK -]
[- Rebuilding MUD executable: merc.exe -]
[- **********Compile Complete********** -]


Line 2710 is listed above, here's 2717:

else if ( !str_cmp( arg1, "mana") && ch->max_mana < manacap)
{
if ( ch->max_mana < 1 ) ch->max_mana = 1; /* Bug fix */
cost = 2 * (ch->max_mana - ch->pcdata->perm_wis);
pAbility = &ch->max_mana; <——————-2717 is here
pOutput = "mana";
}


and 2725:

else if ( !str_cmp( arg1, "move") && ch->max_move < movecap)
{
if ( ch->max_move < 1 ) ch->max_move = 1; /* Bug fix */
cost = 2 * (ch->max_move - ch->pcdata->perm_con);
pAbility = &ch->max_move; <——————————–2725 is here
pOutput = "move";
}


So the errors on the server are likely to be the same lines, it's just max_hp mana and move cause I increased them to int from sh_int. What would I need to do to correct these. Perhaps I'll understand what you said previously if I can see how it is put into use with this code. By the way, this is basically the stock do_train from low4. I haven't changed much except for numbers in it, I've added other things but not in the parts in question.
06 Feb, 2009, Igabod wrote in the 19th comment:
Votes: 0
Ok I decided just to tinker with line 2710 and removing the () from int * allowed it to compile, I've still got a bunch of warnings but it compiled completely at least.

The message for act_move.c now is as follows:

–>  Compiling file: act_move.c  <–
act_move.c: In function âdo_trainâ:
act_move.c:2709: warning: unused variable âpAbilityâ
act_move.c:2716: warning: assignment from incompatible pointer type
act_move.c:2724: warning: assignment from incompatible pointer type
act_move.c:2533: warning: âpAbilityâ may be used uninitialized in this function
[- act_move.c compiled OK -]


This worries me cause it's saying pAbility is unused now, but it shouldn't be. I don't know what's going on with this, but the other warnings are pretty simple fixes. Any insight would be nice.

[edit to add] sure enough, the mud crashes when I train hp. I'll probably post a gdb backtrace in a little bit, don't feel like doing it right now.
06 Feb, 2009, Sharmair wrote in the 20th comment:
Votes: 0
Igabod said:
Ok I decided just to tinker with line 2710 and removing the () from int * allowed it to compile, I've still got a bunch of warnings but it compiled completely at least.

The message for act_move.c now is as follows:

–>  Compiling file: act_move.c  <–
act_move.c: In function âdo_trainâ:
act_move.c:2709: warning: unused variable âpAbilityâ
act_move.c:2716: warning: assignment from incompatible pointer type
act_move.c:2724: warning: assignment from incompatible pointer type
act_move.c:2533: warning: âpAbilityâ may be used uninitialized in this function
[- act_move.c compiled OK -]


This worries me cause it's saying pAbility is unused now, but it shouldn't be. I don't know what's going on with this, but the other warnings are pretty simple fixes. Any insight would be nice.

[edit to add] sure enough, the mud crashes when I train hp. I'll probably post a gdb backtrace in a little bit, don't feel like doing it right now.

OK, first to explain what you did. If you removed just the () from the cast, you made that line a
definition of a new pAbility (this time a pointer to an int) local to the scope of the if statement
(the if with the str_cmp to hp). It then goes out of scope at the end of the if, not being used
after the definition. This also creates a control path that never uses the function level pAbility,
thus causing the warning about that pAbility possibly being used uninitialized (which you actually
do causing a crash). In case I did not make that clear enough, you had two variables of the same
name, the new one hiding the old one when you are in the hp' if.

You should remove the whole cast (the int * part too), this should get rid of the error (but
replace it with a warning about assignment from incompatible pointer types, like the other
two you are getting). The code might even more or less work (if the cpu is little endian and
the stat modification does not span the short range limit), but it really is in error. This
warning is from assigning a int* to a sh_int*.

A fix would be like the code I talked about before, but as I have more info now as to the
details of how you are setup now, I will try to give instructions making assumptions that
have a good chance of being closer to what you have.

Close to the top of the function, find:
sh_int *pAbility;

Replace with:
sh_int* pAbility = NULL;
int* pIntAbil = NULL;

Then in the three lines that are giving the assignment warnings (the first being the line with
the error now), replace pAbility with pIntAbil. Ok, this last part I have to make the assumption
that all the ability mods are one point and go through a common set code at the end of the
function.
Close to the end of the function, find something like:
*pAbility      += 1;

And replace with:
if(pAbility)
*pAbility += 1;
else if(pIntAbil)
*pIntAbil += 1;
0.0/57