23 Nov, 2013, Grieffels wrote in the 1st comment:
Votes: 0
So I was going through some of Darien's work, I believe that is the name, and I ran across something that says it could save your MUD. All I can say is WOW. I don't know where to start. I added -ansi to my Makefile and I was completely FLOODED by errors.

CHAR_DATA has no member named ' ' over and over. The same thing for PC_DATA.
Without -ansi in the Makefile everything compiles perfect, but with it, I honestly feel bad. It made me feel like this game is complete garbage so now for the next week (I said week, which probably means three weeks) I am going to be debugging. However, I need some assistance.

For starters, char_data in merc.h has these so called errors in the structure. So I don't know how to make it so it has that member. Are the files not linking to merc.h correctly somehow? I'm really just not understanding it as to why it says they aren't there. I am noticing however that most of these errors are coming from things that consist of SET_BIT, REMOVE_BIT and such.

#define REMOVE_BIT(var, bit) ((var) &= ~(bit))
A line that is erroring: REMOVE_BIT( ch->affected_by, AFF_HIDE);
It's not just those at all, but that is just an example.
Anyway, I would appriciate it if someone could push me in the direction of fixing this because honestly, I feel bad for this MUD after doing -ansi. I know it's not needed but honestly, I know that it will run better after fixing all of this. It would have too.
23 Nov, 2013, quixadhal wrote in the 2nd comment:
Votes: 0
You might want to take a look at the RaM project, specifically the "Ice" version. That was a project to update ROM to include all the commonly known bugfixes, as well as make it cleaner and a bit more modern with respect to the tools of the day. The "Ice" version was the last one that compiled using plain old gcc, before the "Fire" version started adding in C++ features.

It may (or may not) compile cleaning today, but we did a fair amount of work to make it happy with the version of gcc available at the time, which is much closer than the original code from almost 20 years ago.

There should be a snapshot in the reository, likely under the ROM hierarchy.
23 Nov, 2013, Grieffels wrote in the 3rd comment:
Votes: 0
I will take a look at that now, actually. I have to add though, I can't go back now. Too much has been modified in this and changed for me to want to add everything back to another base. I will go through and fix errors that are listed that haven't already been tendered too. Even with that said, I just want to say my MUD compiles with that flag in the Makefile. Also, with everything that has happened in my life recently, im trying my hardest to keep my mind occupied. The loss of a child is the hardest thing ill ever deal with. No sorry, nothing like that please. Just MUD talk.
23 Nov, 2013, Vigud wrote in the 4th comment:
Votes: 0
Choosing -ansi in gcc will disable any other standards (like POSIX) if you don't add a definition of a feature macro like _POSIX_C_SOURCE or _XOPEN_SOURCE. I bet the code uses functions from outside the ANSI C standard, so it won't compile in strict (stricter than what gcc usually does – to be precise) ANSI standard mode.

http://gcc.gnu.org/onlinedocs/gcc/Standa...
http://www.gnu.org/software/libc/manual/...
23 Nov, 2013, Grieffels wrote in the 5th comment:
Votes: 0
A problem I am having, is I can't see the top line of error. It spams so much, putty doesn't allow me to scroll that high. Is there a way I can see the errors?
23 Nov, 2013, Tyche wrote in the 6th comment:
Votes: 0
Under bash, this would redirect to a file:
make > make.log 2>&1
24 Nov, 2013, quixadhal wrote in the 7th comment:
Votes: 0
You might also want to change your system locale, as by default (on modern linux systems), the locale seems to be UTF-8, which makes gcc enable highlighting of error messages using characters that tend to not render nicely on normal (ANSI) terminals or forum software.
24 Nov, 2013, Grieffels wrote in the 8th comment:
Votes: 0
What would I change it too? All the ones I have listed now = "C"
24 Nov, 2013, quixadhal wrote in the 9th comment:
Votes: 0
C is "normal", so you're set. Many folks post errors on here with bizzaro characters in the error logs, because if the locale is UTF-8, gcc (and other GNU tools) add coloring and other highlighting to their error output, and that always gets messy when pasted.
25 Nov, 2013, Grieffels wrote in the 10th comment:
Votes: 0
Thanks everyone for your help.
Tyche, I did what you said with bash: in the Makefile and it worked perfectly. Thanks.

I do have another question. With -Wshadow added to the Makefile, I get what it's doing, I just don't know if removing ALL of the shadows is a good thing. For example, buf[100]; at the top of the function where you'd declare ints and such. Further in the code there is a call for buf[MAX_STRING_LENGTH]; I was wondering if anyone would care to inform me on why or why I shouldnt remove those if it fixes that error. Also GLOBAL shadow from files like merc.h and then in the .c file it has it showing up differently. Should I fix those or maybe make a new variable for it in the c file and not reuse that shadowed variable/int?

Also, instead of making a new post on this I figured I would just post it here seeing as how i've been posting new things alot and don't want to spam the place with posts by Grief.
25 Nov, 2013, Vigud wrote in the 11th comment:
Votes: 0
It's nice to have all those fixed properly, so that you can use -Wshadow permanently as your compiler's option, in order to see the warning when you create new code that triggers the warning – then you immediately have the chance to think about which of the two objects you really mean to use.

But the key here is that existing instances of the warning-triggering code need to be fixed properly. Sometimes removing the latter object will suffice, sometimes you'll have to rename one of them; but you always need to think about the consequences of that. It's pretty easy to do it wrong and silence a harmless warning while introducing real bugs.

This actually applies to all kinds of warnings.
25 Nov, 2013, Kaz wrote in the 12th comment:
Votes: 0
Quote
I was wondering if anyone would care to inform me on why or why I shouldnt remove those if it fixes that error.


Consider:

void fn
{
buf foo[SOME_CONSTANT];

// …

while (bar)
{
buf foo[SOME_SMALLER_CONSTANT];

// …

memcpy(foo, baz, SOME_CONSTANT);
}
}


At a glance it might look fine because, hey, there's a foo with a size of SOME_BIGGER_CONSTANT, but it's a crash waiting to happen.
25 Nov, 2013, Tyche wrote in the 13th comment:
Votes: 0
Sometimes it's a logic error, sometimes it's not.
26 Nov, 2013, Kaz wrote in the 14th comment:
Votes: 0
On reflection, it appears I've answered exactly the opposite question. Oh well.

The only reason to avoid getting rid of shadowed variables would be if there was a benefit in having variables shadowed. There isn't; there are only pitfalls. They're legal, but it's a good idea in general to be rid of them IMO.
26 Nov, 2013, Grieffels wrote in the 15th comment:
Votes: 0
Thanks again everyone.
0.0/15