Login
User Name:

Password:



Register

Forgot your password?
Changes list / Addchange
Author: Khonsu
Submitted by: Khonsu
6Dragons mp3 sound pack
Author: Vladaar
Submitted by: Vladaar
AFKMud 2.2.3
Author: AFKMud Team
Submitted by: Samson
SWFOTEFUSS 1.5
Author: Various
Submitted by: Samson
SWRFUSS 1.4
Author: Various
Submitted by: Samson
Users Online
Google, Majestic-12

Members: 0
Guests: 25
Stats
Files
Topics
Posts
Members
Newest Member
488
3,788
19,631
595
Khonsu

Today's Birthdays
There are no member birthdays today.
» SmaugMuds » 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 ... 4, 5, 6, 7, 8 next >>
Post is unread #121 Aug 31, 2008 12:59 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 running g++ 4.2.3 and am not getting this error. What version of g++ are you using?

Anyhow, the fix is simple...

Post is unread #122 Aug 31, 2008 1:18 am   
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002

 
Zeno said:

I'm fairly certain before this fix we had warnings which did not compile due to Werror, and I recommended simply not using Werror.

Now we're getting actual errors.


Yep, and that's also one reason why I stood so firmly against removing the Werror flag since GNU has a nasty habit of making previously trivial warnings into hard errors with new releases :)

Post is unread #123 Aug 31, 2008 11:36 am   
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

 
Let's see, this server has: gcc version 3.3.6


A habit does not guarantee they'd do that though. While it may seem like the safe thing to do, it has already created more problems. The fix may be simple, but by the time the fix gets applied who knows how many people have DLed FUSS, ran into the error and gave up when it error'd out in the first second.

Post is unread #124 Aug 31, 2008 12:01 pm   
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

 
It might be time to finally consider the idea of a proper dependency list.

As time marches on, it's obvious that some things change in ways that aren't always going to be backwards compatible. It's a HUGE amount of effort to maintain code using something like autoconf, but that's about the only reasonable way I know to allow code to compile on multiple environments AND multiple versions of those environments.

If we now have something which cannot compile on both gcc 3.3.x AND gcc 4.2.x, we have the choice of either using something to detect the compilation enviornment and adapt things accordingly (even if it's just toggling -Werror), or saying that as of version 1.x, SmaugFUSS is only supported on platforms with gcc 4.x or higher.

In any case, it might be good to start making that list. :)

Post is unread #125 Aug 31, 2008 12:09 pm   
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

 
The last thing I want to see happen is removing backwards compatibility.

Post is unread #126 Aug 31, 2008 12:39 pm   
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002

 
All the while Zeno, you haven't told anyone exactly what errors are coming up. Just because there's a Werror tag doesn't mean it's broken or a bad thing. The errors may well be fixable. Or as has also happened in past GCC updates, they may be bogus and the current compilers may be making the right call in allowing the code to work.

Maintaining backward compatibility is fine right up until it holds back advancement. Microsoft hit that wall when XP came along and they're still up against it now because of Windows 98 and their insistence on keeping enough compatibility in place for apps that once ran on it. The same thing will happen here if we insist on maintaining backward compatibility with such old compilers as 2.x and 3.x.

Post is unread #127 Aug 31, 2008 2:59 pm   
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

 
So what would you have suggested, Zeno? Leave in all of the const problems, knowing that they have caused problems like segfaults for us in the past? The errors you are seeing are trivial to fix in the main distribution. Oops: it didn't compile perfectly on all compilers the first time around. No biggie, it's not as if it's the first time that's happened. Seriously though, it sounds like you would have left everything as is and just turned off the -Werror flag? I'm not a big fan of it myself but leaving so many warnings that are actually relatively serious is something I like even less...

Post is unread #128 Aug 31, 2008 3:42 pm   Last edited Aug 31, 2008 3:43 pm by Zeno
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

 
All the while Zeno, you haven't told anyone exactly what errors are coming up.

I already posted the exact errors and lines in this thread on the last page.

So what would you have suggested, Zeno? Leave in all of the const problems, knowing that they have caused problems like segfaults for us in the past?

Have they? Are these const problems part of stock Smaug? Because I've been running an old version of FUSS for 5+ years now and haven't ran into this segfault issue with them.

Post is unread #129 Aug 31, 2008 6:19 pm   
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

 
Zeno said:

Are these const problems part of stock Smaug?

I would be astounded if they weren't.

Zeno said:

Because I've been running an old version of FUSS for 5+ years now and haven't ran into this segfault issue with them.

There was a bug report here having to do with socials causing a crash when something tried to capitalize a string literal.

Anyhow, the constness of the code was simply wrong -- why is it so bad to fix it? So the fix wasn't perfect at first; well, that's not great, but it's not the end of the world, either.

Post is unread #130 Aug 31, 2008 6:31 pm   
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

 
Glanced at the bugfix section, didn't see it. Do you have a link for that? Doesn't ring a bell.

Post is unread #131 Aug 31, 2008 6:55 pm   
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

 
Post is unread #132 Aug 31, 2008 7:09 pm   
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

 
How would that be reproduced in stock? It doesn't seem that clear.

Post is unread #133 Aug 31, 2008 7:16 pm   
Go to the top of the page
Go to the bottom of the page

InfiniteAxis
Off the Edge of the Map
GroupAdministrators
Posts1,200
JoinedMar 21, 2006

 
I already posted the exact errors and lines in this thread on the last page.


Remove the const before IMC_FUN. That fixes the problem.


And the fact of that matter is, that the const char* shit needed fixed, so it got fixed. Nothing's perfect the first time around, we found a slight error in the const fix. So we fix it and move on to looking for others.

At the time, the socials bug was reproduced in stock. I'm pretty sure you were the one that confirmed it in stock as well, Zeno.

Post is unread #134 Aug 31, 2008 7:59 pm   
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

 
Zeno said:

Let's see, this server has: gcc version 3.3.6

Just wait, the new server that SBI is sitting on has version 3.3.6 available for you (along with 3.4.6 & 4.1.3) should you decide to change your Makefile to use it (by changing your CC: line from gcc to gcc -V 3.3), but just running gcc on it will invoke version 4.2.3 (-2ubuntu7 in fact) and the 64-bit version to boot.. (the others are all 64-bit too since the new box is running the 64-bit version of Ubuntu 8.04 now.)

Oh, and the box it had been running on up until Thursday night was using version 3.3.4 (32 bit version compiled for Redhat's FC3). It's been a fun weekend so far. *sigh*

Post is unread #135 Sep 1, 2008 12:15 am   
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002

 
Completely random off topic tangent. But Conner, what happened to all your avatar and sig images?

Post is unread #136 Sep 1, 2008 12:26 am   Last edited Sep 1, 2008 12:26 am by Kayle
Go to the top of the page
Go to the bottom of the page

InfiniteAxis
Off the Edge of the Map
GroupAdministrators
Posts1,200
JoinedMar 21, 2006

 
His Server is currently missing a NIC, and he's been working all weekend to get the new servers set up and get everything copied over.

[Edit for grammar correction.]

Post is unread #137 Sep 1, 2008 3:28 am   Last edited Sep 1, 2008 3:29 am by Conner
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

 
Actually.. no, although you are right that it has to do with the server transition that's been driving me nuts all weekend. My server (both old and new) still has it's second NIC, but the old server's no longer running the web server daemon and the new server, which is otherwise all done (more or less) and ready to be swapped in, has developed a dislike for IPv4 all of the sudden which is making it really hard to even resolve the problem since my ISP assigns dynamic IP via IPv4 and my LAN is IPv4 based.. Dragona and I are currently working on it (even my muds and those I host have already been switched to the new box *sigh*), I'm just taking a quick forum break because the networking config stuff was making me feel the need to do so... :redface:

Post is unread #138 Sep 1, 2008 3:43 am   
Go to the top of the page
Go to the bottom of the page

InfiniteAxis
Off the Edge of the Map
GroupAdministrators
Posts1,200
JoinedMar 21, 2006

 
Oh, I thought I saw somewhere that your NIC had blown up.

Post is unread #139 Sep 1, 2008 6:31 am   
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

 
You did read that on MudBytes but it was the one in my BBS machine rather than the server (which hosts my web sites, muds, and so on plus acts as my firewall and file server and... :wink:), this weekend's efforts are just a long overdue server replacement.

Post is unread #140 Sep 1, 2008 12:23 pm   
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

 
Good luck on the upgrade Conner! Hardware sucks. :)

Warning: BOOK ahead. I guess I'm in narration mode today, sorry!


The argument of not believing a problem exists because it hasn't happened to you, personally, reminds me of an old comic argument involving cartographers.

"Why do we need to redraw all these maps? They're fine!"
"Well, no, they're all wrong. Those maps were drawn by people who believed the world was flat. We now know it's round, and so the scale of everything is off."
"Are you SURE? I've been sailing from these maps for years and always found my way around."
"Yes! You can't accurately draw a map of a sphere on a flat rectangle unless you use one of these methods that warps the lines to simulate the curve."
"I dunno. Have you checked to make sure the world is REALLY round? I trust these maps a lot more than I trust your theories!"


The fact is, compilers don't really have all THAT many bugs, per se. It's a pretty rare event for someone to find a compiler bug that produces incorrect (assembly) code, and those get jumped on pretty quick. The vast majority of patches done to compilers are to tighten up error handling and detection. gcc 4.x checks for a great many things, in terms of code usage, that gcc 3.x didn't even try to check.

It's entirely possible to have code that works perfectly for years, suddenly break with a new compiler. Sometimes that's because it now detects things you did wrong, but got away with. Sometimes, the compiler itself now handles things differently and the way you did things before doesn't work. How can you tell the difference? You can try gcc -S. That produces assembly code. If you have the old and new compilers both installed, you can have them each compile the same file and then look at the resulting assembly code.

Does it matter? Well, not really. In computers, we have two options. You can stop upgrading at a "tried and true" version, and live with the fact that you will gradually be left behind and that fewer and fewer people will be able to use what you produce, or you can keep upgrading and going back to revise your code.

I've nursed WileyMUD from it's original home on a Sun 3/60 running SunOS 3.x (Motorola 68040 CPU, SunOS was mostly BSD-derived), to a Sun 4/110 running SunOS 4.x (SPARC CPU), to a Sparc 10 running Solaris (Solaris is mostly SYSV-derived), and then to an i486 Linux 1.1.x box (Slackware), a Pentium 90 box (Redhat), a P333 box (OpenBSD!), and finally the P3-933 (Debian) box it's sitting on now.

In that 15 year journey, we've gone from the stock /bin/cc that SunOS provides, to gcc 2.x, to the stock cc from Solaris, to gcc 3.x in several environments, and to gcc-4.1.2 now. EVERY time I've had to go through and re-fix things, and almost every time I've found things that someone (maybe me, maybe the Diku authors, maybe one of the other devs from years ago) did that was clearly wrong, but that the older compiler let slide.

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."

Pages:<< prev ... 4, 5, 6, 7, 8 next >>