Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Sogou, Google

Members: 0
Guests: 1
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » General Discussions » How do we handle the errors c...
Forum Rules | Mark all | Recent Posts
How do we handle the errors caused by gcc4.2? (14 Votes)
Update to const char *argument and adjust all the rest of the code accordingly.  57.14% - 8 votes

Modernize and update to std::string throughout the code.  42.86% - 6 votes

Other. (Post an explanation of your alternative solution.)  0% - 0 votes

How do we handle the errors caused by gcc4.2?
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3, 4, 5 ... next >>
Post is unread #1 May 18, 2008, 7:10 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

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.
       
Post is unread #2 May 18, 2008, 7:27 pm   Last edited May 18, 2008, 7:28 pm by David Haley
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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.
       
Post is unread #3 May 18, 2008, 7:35 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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?
       
Post is unread #4 May 18, 2008, 7:43 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

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?
       
Post is unread #5 May 19, 2008, 5:21 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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. :thinking:

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)
       
Post is unread #6 May 19, 2008, 5:39 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

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. ;)
       
Post is unread #7 May 20, 2008, 6:37 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Hrm. 7 votes. 3 explanations. Could the invisible voters please give an explanation about why they chose the options they did? Thanks.
       
Post is unread #8 May 20, 2008, 5:36 pm
Go to the top of the page
Go to the bottom of the page

Darwin
Fledgling
GroupMembers
Posts37
JoinedOct 10, 2007

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.
       
Post is unread #9 May 21, 2008, 6:06 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

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.
       
Post is unread #10 May 21, 2008, 10:40 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

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?
       
Post is unread #11 May 21, 2008, 7:43 pm
Go to the top of the page
Go to the bottom of the page

Keberus
Conjurer
GroupFUSS Project Team
Posts341
JoinedJun 4, 2005


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.
       
Post is unread #12 May 21, 2008, 10:02 pm   Last edited May 21, 2008, 10:06 pm by David Haley
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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.
       
Post is unread #13 May 21, 2008, 10:10 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Thanks a lot David. :)
       
Post is unread #14 May 30, 2008, 9:07 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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.
       
Post is unread #15 May 30, 2008, 9:19 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

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.
       
Post is unread #16 May 30, 2008, 9:50 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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. :wink:
       
Post is unread #17 May 30, 2008, 11:36 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

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.
       
Post is unread #18 May 30, 2008, 12:19 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

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... :thinking:
       
Post is unread #19 Jun 7, 2008, 12:27 pm
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts367
JoinedMar 7, 2005


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. :wink:

       
Post is unread #20 Jun 19, 2008, 9:49 pm
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts367
JoinedMar 7, 2005

Er... bump? :thinking:
       
Pages:<< prev 1, 2, 3, 4, 5 ... next >>