01 Apr, 2009, Igabod wrote in the 1st comment:
Votes: 0
I've finally decided to get around to fixing all the shadowed declarations in my code but wasn't sure exactly how to go about this. Everything I could find on google said I should just comment out whatever is being shadowed but that sounds pretty stupid to me because of the first warning I get for that. Here's what my compile gives me:

–>  Compiling file: act_comm.c  <–
In file included from act_comm.c:33:
merc.h:4292: warning: declaration of `index' shadows a global declaration
/usr/include/string.h:310: warning: shadowed declaration is here
merc.h:4308: warning: declaration of `act' shadows a global declaration
merc.h:4036: warning: shadowed declaration is here
act_comm.c: In function `do_group':
act_comm.c:1986: warning: declaration of `leader' shadows a global declaration
merc.h:2839: warning: shadowed declaration is here
make: *** [obj/act_comm.o] Error 1

I'm just gonna skip to the act_comm.c:1986 one here

void do_group( CHAR_DATA *ch, char *argument )
CHAR_DATA *victim;

one_argument( argument, arg );

if ( arg[0] == '\0' )
CHAR_DATA *leader;<——–line 1986

and in merc.h:2839:

extern          LEADER_DATA       *     leader[6];

however these are two different pieces of info that use the term leader. act_comm.c is group leader and the merc.h one is for the leader command that displays the top pkillers etc. It would be entirely too much effort to change either of these instances to something different. Is there another method to correct these warnings?
01 Apr, 2009, Guest wrote in the 2nd comment:
Votes: 0
Simple method is to just change the name of the temporary variable in act_comm.c on line 1986. If it's supposed to be a group leader, change it to gleader and make sure the references to it further down get changed to match.
01 Apr, 2009, Igabod wrote in the 3rd comment:
Votes: 0
the problem with that is group leader is also in the pfile and changing it would mean I'd screw up all the pfiles and would have to do a pwipe. I'm looking for a solution that doesn't require a pwipe.

[edit to add] looking through save.c I don't see leader mentioned anywhere but everywhere in the code there's references to ch->leader which would be the group leader. I still think this could cause problems with the pfiles though, if anybody can provide me contrary information that would be extremely helpful.
01 Apr, 2009, Guest wrote in the 4th comment:
Votes: 0
It wouldn't require a pwipe. In a function such as what you listed, the variable name on line 1986 is temporary. It's not stored. The code is only using it as a pointer to the real data. As soon as that function is done doing its work the variable simply vanishes.
01 Apr, 2009, Igabod wrote in the 5th comment:
Votes: 0
so I should just change line 1986 to CHAR_DATA *gleader; and all the other references to leader in the function as well? The next line in the function is this:

leader = (ch->leader != NULL) ? ch->leader : ch;

do I change each instance of the word leader here too? and if so then I'd have to change the other references to ch->leader (group leader) in the code wouldn't I?
01 Apr, 2009, Guest wrote in the 6th comment:
Votes: 0
Well that by itself won't. You have to look at the rest of that part of the function and make sure it uses gleader instead of leader, otherwise you'll find out pretty quickly why the compiler warns you not to shadow names :)
01 Apr, 2009, Igabod wrote in the 7th comment:
Votes: 0
I edited my post while you were typing apparently.
01 Apr, 2009, Guest wrote in the 8th comment:
Votes: 0
You'd only want to change "leader" to "gleader". ch->leader is an entirely different variable which should be left alone unless the compiler begins complaining about it too because of that other array.
01 Apr, 2009, Igabod wrote in the 9th comment:
Votes: 0
Ah, thanks for that samson. Though I think I'm just gonna say screw this and remove -Wshadow from my makefile. This is retarded now that I've looked at the next set of warnings. I'm just too lazy and too unskilled to attempt to tackle this at the moment, and if it works why bother. I really don't like having any warnings but I'll have to deal with it. Again, I appreciate your help with that one, it means that's one less I will have to tackle when I decide to stop being lazy.
01 Apr, 2009, David Haley wrote in the 10th comment:
Votes: 0
(This is a great example of a problem that should be solved by good naming conventions; a local variable shouldn't have the same name as a global variable.)
02 Apr, 2009, Igabod wrote in the 11th comment:
Votes: 0
I'll probably get around to fixing all these stupid warnings one day in the distant future, but till then I've got a lot of cleaning up to do in this code. Every day I'm filled with rage upon seeing the kind of crap that was allowed to slip by in the LoW4 code. There's a bunch of crap that was just copy/pasted in and not formatted. There's also a bunch of places where Sage commented out an entire function just because one part wasn't working, and he just rewrote the function almost exactly the same but with one or two lines changed. Cleaning up a huge mess like this is good experience gathering for me, but it's still frustrating.
02 Apr, 2009, David Haley wrote in the 12th comment:
Votes: 0
Somebody wise once said:
Experience is what you get when you don't get what you want

02 Apr, 2009, Igabod wrote in the 13th comment:
Votes: 0
that sounds like calvin and hobbes… I could be wrong though :grinning: