Quixadhal said:

Good luck on the upgrade Conner! Hardware sucks.

Thanks, currently it's trying hard to suck even worse than it should be and I'm not sure if the problem is actually in-house. *mutter*

Quixadhal said:

gcc 4.x checks for a great many things, in terms of code usage, that gcc 3.x didn't even try to check.

Actually, I'd take that a step further and posit that there are significant differences even between gcc 4.1.x and 4.2.x since my mud, in it's present state, compiles just fine under gcc 4.1.3 but will not compile under 4.2.3 because of complaints about stdarg.h (and I've got flags in my Makefile to stop on errors so that's the only complaint I know of because it won't go beyond that one...)

Quixadhal said:

I think people who are already here, and already use Smaug, will be able to adapt to changes as they come along. I don't want to abandon folks on older systems either, but I also don't want to see things stall out because too much energy is being devoted to keeping things running on the older systems.

It might be as simple as putting some comments in the Makefile on ways to get things running with older compilers. "If you're using gcc 3.x, disable these warnings. If you're in FreeBSD, do this. In ALL cases, be aware that things might be broken if you do this."

I'd be inclined to agree entirely with this but I have to ask if it really would be as simple as a line or two of commented out instructions? (Even just per compiler/OS?)

There are some minor things that are as easy as putting in a toggle flag in the Makefile. That's how the Cygwin support works for one. Toggle a flag, the code compiles extra stuff it wouldn't do otherwise.

The problem comes when the difference between compilers creates a situation as completely insane as the const fix. That's not something you can correct with a simple flag. To fix that you really do need to go down into the dirty levels of the code and bring it up to speed the hard way. One error at a time.

Oh, I didn't mean a single flag would FIX the problem. Rather, it would allow people to compile things and ignore the various warnings AT THEIR OWN RISK.

Personally, I'd rather have things error and fail at compile time, than risk crashes at run time. However, if all you're doing is downloading the MUD to see if you like it, getting it to work is probably more important than making sure it's 100% stable. That's why I'd put things like that in comments. If you understand the risk, and you're OK with it, here's how to get it to run until you can upgrade, or we can find a way to help you fix it for your particular environment.

Just as an amusing "proof" of why turning off warnings is a bad idea..... Here's a bug I JUST fixed from my old mud, which has been there since 1995.

WileyMUD was written before Smaug existed, and so all the spell code is usually cut and pasted from one spell to another (no generic spell_smaug yet). Well, there are both spell_blah() routines to do the actual spell, and cast_blah() routines as the API to cast the spell. When you call cast_, it checks to see how the spell is being invoked, as in cast as a spell, read from a scroll, etc... so there's a case statement for that.

With that as background, this will make sense:

void cast_weakness(char level, struct char_data *ch, char *arg, int type,
                   struct char_data *victim, struct obj_data *tar_obj)
{
  if (DEBUG > 1)
    dlog("called %s with %d, %s, %s, %d, %s, %s", __PRETTY_FUNCTION__, level, SAFE_NAME(ch), VNULL(arg), type, SAFE_NAME(victim), SAFE_ONAME(tar_obj));

  switch (type) {
    case SPELL_TYPE_SPELL:
      spell_weakness(level, ch, victim, 0);
      break;
    case SPELL_TYPE_POTION:
      spell_weakness(level, ch, ch, 0);
      break;
    case SPELL_TYPE_SCROLL:
      if (tar_obj)
        return;
      if (!victim)
        victim = ch;
      spell_weakness(level, ch, victim, 0);
      break;
    case SPELL_TYPE_STAFF:
      for (victim = real_roomp(ch->in_room)->people; victim; victim = victim->next_in_room)

==>     if (!in_group) <==
          spell_weakness(level, ch, victim, 0);

      break;
    default:
      bug("Serious screw-up in weakness!");
      break;
  }
}

I was recompiling to see how many things had broken due to gcc upgrades over the last year or so, and gcc 4.1.2 spat this warning out at me today:

spells.c: In function 'cast_weakness':
spells.c:2768: warning: the address of 'in_group', will always evaluate as 'true'

The line that I highlighted should have read:

 if(!in_group(victim, ch)) 

SO... IF someone had actually tried to use a staff which had the weakness spell associated with it, the game would not have crashed, but the spell would not actually have been cast on anyone, since it would have spun through the loop of people in the room and decided they were ALL in the caster's group.

Warnings are good.

Even the annoying "use of sigsetmask() is depreciated, go learn another API old fart!" one.

I don't think anyone here was suggesting to turn off warnings.

Personally I was talking about not handling warnings as errors.

True, although part of the reason I treat all warnings as errors is that it forces me to go fix them.

On the occasion I find one I don't want/need to fix right away (the sigsetmask one, for example), I'll remove the -Werror flag to get a build done, but I put it back so I don't just forget about it.

When I tried recompiling with the newer gcc (4.1.2), I got about 35 new warnings, and so it wasn't hard to spot that error. Other codebases I've looked at have had, literally, hundreds of warnings. Enough that critical errors would just get buried in the flood.

I guess I tend to think that either people already plan to fix every warning, in which case it doesn' t matter if they're errors or not... or they intend to only fix the things they have to, in which case errors like the one I had above would slip through the cracks.

I eventually fix all warnings, where eventually is in the not-too-distant future. I know which warnings are actually important and which I can get away with putting off for a while. Sometimes I think it's more important to just press ahead, in which case I really don't want warnings treated as errors. I never use the flag because I would have to keep turning it on and off; that would get on my nerves pretty quickly. Basically I am my own -Werror flag -- I allow minor warnings in the short term (important warnings always get fixed), especially during development, but I fix them when I go to production.

I really don't get why this discussion about the -Werror flag is still going on.. the packages are shipping with the -Werror flag enabled.. If you don't want it on.. delete it from the makefile when you download it..

I think people were talking about how they do their own development. The flag is only relevant in FUSS when we run into one of the issues like we did for this time around.

Oh, my bad. I thought we were still rating about how warnings as errors are the devil.

lint main.c
if [ "$?" -ne 0 ]; then
  echo "Blaspheme!  Thy code is not PERFECT in the eyes of lint!"
  rm -f main.c
fi

*grin*