So the times has come to really think about how we, as a project should handle the errors caused by the recent changes to the compiler with gcc4.2. Please vote only once, and please explain your choice.

Let's try to keep this as civil as possible, I'm not opening the floodgates for a shit slinging contest. And I'm not going to tolerate it.

I voted to fix the constness, not because I think it's a better solution in the absolute but because I think it can be completed more quickly. IMO it is the better short-term solution. Modernizing will require planning and thought, which means it could be months before such an undertaking even moves to the code phase.

In the meantime, the code simply does not compile for some people and that really isn't acceptable for anybody, not the least of which is the project that looks bad by shipping apparently broken code. That means either removing the -Werror flag or fixing the constness. Since the first has been ruled out as an option, that pretty much only leaves the second for the short term.

Another short-term option could be to make it more obvious that if people are getting such warnings, they can just remove -Werror from the makefile. That said, the const problems really are problems in the end of the day (bug-prone as we have seen) and should be fixed one way or the other.

I voted for option 1 because it's probably the fastest way to deal with it. The vast majority of what the compiler claims to be broken simply isn't, but obviously we won't convince GNU of that. If projects the size of KDE can't sway their pigheaded ways, we sure won't. So it needs fixing.

I'd prefer to go the long-term route eventually and modernize, but that's far too much work for so little short term gain. And suppose GNU pulls another flagrant warning move like this again later?

Now that others have posted, and it won't look like I double posted.

I voted for option 2, because of the long term bonuses of swapping out to std::string, but I see the point to getting it fixed ASAP. Perhaps we should fix it now, and then consider the option of swapping out to std::string later because of the benefits?

Well, in all cases, something has to happen now, right? Unless it is considered ok for the codebase to ship in a state that doesn't compile, which probably isn't good for anybody.

I think there are really two questions here: what should be done now and what should be done in the long term.

(Greetings from NYC... Red-eye flights are teh sux0r)

Well, I've applied a temporary solution to all the FUSS bases. Namely, there's a disclaimer about the problems with gcc4.2 and that to get around it, all they have to do is either compile on gcc4 or 4.1 or remove the -Werror flag from the Makefile.

I think though, for now, it seems like the best solution is going to be to fix the const issue, and then begin plans for a conversion to std::string. Any volunteers? Only thing I'd be able to accomplish is screwing it up more, with my lack of ability to work with strings.

Hrm. 7 votes. 3 explanations. Could the invisible voters please give an explanation about why they chose the options they did? Thanks.

My vote: Update to const char *argument and adjust all the rest of the code accordingly.

I voted for that because it would seem to take less time to complete.

Updating the code to remove the warnings (usually by sprinkling a sufficient quantity of casts around, or in some cases removing them) is probably the most straightforward solution, and that's what I voted for.

On the plus side, it's very unlikely that anything we fix will make it broken on older compilers that currently don't complain. As Samson said, GCC 4 is far more aggressive about warning conditions that GCC 3. That's good for catching subtle errors you might otherwise bang your head against the wall trying to figure out... but a pain in the arse when real-world code doesn't follow some arbitrary spec exactly.

Converting to std::string would be nice, but to do it right will require backing up a few steps and taking a good long look at many bits of the code to see what needs to be scrapped and redone, and what can be hammered into place. I know I'd feel more comfortable doing big changes like that once all the little nitpicky things are cleaned up so I know any warnings are from changes, and not leftovers.

So far the overall consensus seems to be to fix the warnings now, and later on after careful planning, implement a conversion to std::string. Which I'm all for. Converting to std::string may even cut down on some lines of code in Smaug by allowing us to get rid of some old functions entirely.

So I guess the next question is, Is anyone willing to take a fresh copy of FUSS 1.9 and write up a patch, or document what all needs changed to get rid of the errors?

So I guess the next question is, Is anyone willing to take a fresh copy of FUSS 1.9 and write up a patch, or document what all needs changed to get rid of the errors?

I did it to my mud. To be honest though. I replaced all 'char *' references with 'const char *'....then replaced all 'const const char *' with 'const char *' then started going through and figuring out which functions modify the data they are sent....like one_argument and adjust those accordingly. Problem is...I am still, every once in a while, finding out that I 'const char*'ed one that I shouldn't have and fix it. But at the time it seemed like the easiest way to handle things.

I can take care of it. (Edit: after all, I had already started it on the 1.9 base...) There are some smarter things that can be done than just throwing in casts everywhere. I'll distribute it using version control, which will automatically provide a diff against the original.

Thanks a lot David.

I'm not sure why this didn't occur to us earlier, but another option would be to change the makefile to compile with g++-4.1, not "g++" which might default to g++-4.2. The problem is that not all systems might use the same nomenclature and you might end up with code that reports a missing compiler.

DavidHaley said:

I'm not sure why this didn't occur to us earlier, but another option would be to change the makefile to compile with g++-4.1, not "g++" which might default to g++-4.2. The problem is that not all systems might use the same nomenclature and you might end up with code that reports a missing compiler.

That's at best a temporary fix for a limited audience. Many people won't keep older versions of their compiler around, especially if the upgrade was the result of an automated apt-get yast, or whatever package manager your particular system uses.

If GNU feels gcc 4.2 is stable enough to release it, I would assume they plan to depreciate the 4.1 compiler. I would also expect new OS installations to start migrating to the new compiler as the default. It might take a year, but then we'll be right back at the same place again.

NOTE: I am assuming here that fixing a 4.2 warning does not cause 4.1 to generate a different warning. It wouldn't make sense for it to be that way, but if it does... then it might be a valid argument to try and delay changes until 4.1 is further out of circulation.

My own debian system is using 4.1.2, and debian is notoriously slow at accepting new versions into their non-bleeding-edge distros.

Yes, I meant it as a temporary fix, a better one than removing -Werror entirely.

Quixadhal said:

NOTE: I am assuming here that fixing a 4.2 warning does not cause 4.1 to generate a different warning. It wouldn't make sense for it to be that way, but if it does... then it might be a valid argument to try and delay changes until 4.1 is further out of circulation.

Presumably fixing the code to do the right thing in terms of respecting constness will not generate a different warning... at least, one would hope.

Quixadhal said:

If GNU feels gcc 4.2 is stable enough to release it, I would assume they plan to depreciate the 4.1 compiler. I would also expect new OS installations to start migrating to the new compiler as the default. It might take a year, but then we'll be right back at the same place again.

This scenario is already here, now. GNU not only felt 4.2 was stable, they've released 4.3 which may or may not have pitfalls of its own. Fedora 9 lists gcc 4.3 as their only compiler package. People installing Fedora 9, recent Ubuntu distros, and any other distro that follows these closely will already have problems right now. It isn't going to bite us in a year, it's bitten us already.

Systems that don't have 4.2 or 4.3 yet can still generate the warnings by using the -Wwrite-strings compiler flag. That will expose the warnings ( and oh how I wish it had been left as an optional warning! ) and allow people to see what the fuss ( no pun intended ) is all about. Fixing AFKMud 2.1 using this warning flag confirms that there shouldn't be any more hidden surprises unless 4.2 and/or 4.3 introduce new warnings/errors I can't account for right now. Without upgrading anyway.

I'd love nothing more than to be able to upgrade to Fedora 9, but this issue alone is the only reason it's not possible for me, and I suspect why plenty of other places will have to hold back as well, unless they want to start down the slippery slope of multiple compiler installs.

Samson said:

People installing Fedora 9, recent Ubuntu distros, and any other distro that follows these closely will already have problems right now.

Not really a problem in Ubuntu since Debian and co. keep around several versions of the compiler. I still haven't figured out why Fedora doesn't do the same...

DavidHaley said:

I can take care of it. (Edit: after all, I had already started it on the 1.9 base...) There are some smarter things that can be done than just throwing in casts everywhere. I'll distribute it using version control, which will automatically provide a diff against the original.

Thanks for taking this up and especially for providing diffs. I'm interested in the diffs since I have a lot in common with FUSS 1.9, but not everything, and while tedious, I do want to tackle this at some point when I have the time. Should be worth it when finished though.

Er... bump?