26 Aug, 2008, Lobotomy wrote in the 1st comment:
Votes: 0
Kayle said:
I blame GNU for all our problems!


Why's that? :sad:
26 Aug, 2008, Zenn wrote in the 2nd comment:
Votes: 0
Cuz.. the letters stand for.. Generally Nasty Underscores? Gigantic Northern Utah-nians? Great Big Underachievement?
26 Aug, 2008, Kayle wrote in the 3rd comment:
Votes: 0
I"m just really really frustrated with the boys over at GNU for recent changes to gcc and g++ and causing me so much frustration over this const char* stuff.
26 Aug, 2008, Lobotomy wrote in the 4th comment:
Votes: 0
Kayle said:
I"m just really really frustrated with the boys over at GNU for recent changes to gcc and g++ and causing me so much frustration over this const char* stuff.


'Splain?
26 Aug, 2008, Kayle wrote in the 5th comment:
Votes: 0
I've spent the better part of the last week trying to better understand why GNU has decided to change settings in the compiler to make the -Wwrite-strings flag default to on in gcc/g++ versions 4.2+. For those of us that compile our code in g++ for the stricter compiling, this becomes a major issue with most mud code because we pass char* argument into so many function (at least in the Diku branch). Well, with -Wwrite-strings defaulting to on in newer compilers, this becomes a rather large issue, because well, I'm still not sure why, but thanks to David Haley, I've been slowly grasping the ideas behind it. Basically, to shut the compiler up you have to go through and change all your code to pass a const char* argument into functions. Which in turn causes more problems because you can't directly modify a read-only address, so then you have to go through and change a bunch of stuff to copy to a temporary buffer, make your modifications, pass the temporary buffer on to the next function and then free it. And it's just very frustrating, because of the depth and number of changes I've had to make, and strings were/are not my strongest suit when it comes to coding anyway. I normally have to get help from Davion or David, Occasionally Kiasyn manages to help without confusing me further with his use of RegEx for seemingly everything. :P But it's just all rather frustrating.
26 Aug, 2008, Lobotomy wrote in the 6th comment:
Votes: 0
Shouldn't there be an option to pass a "no" version of -Wwrite-strings, then? Maybe -Wno-write-strings or something. I've been under the impression that for all default compiler options, there is a disabler option. At least, so far that's been the case for me using C.
26 Aug, 2008, Kayle wrote in the 7th comment:
Votes: 0
Well, yes, there is. But as I've come to understand it, passing const char* argument is what's supposed to be done. Safer too, I believe. David could explain it far better than I could.
26 Aug, 2008, Lobotomy wrote in the 8th comment:
Votes: 0
I see.

Also, you mention using g++ for stricter compiling? Are you using it only for that reason, or do you program in C++? I ask, because as far as my understanding has been, that if you compile with g++ you lose access to the C99 revisions (or most of them) of C, in C++. C99 is one of the major reasons I'm still using C and not C++.
26 Aug, 2008, Kayle wrote in the 9th comment:
Votes: 0
I'm slowly converting my code over to C++, but it started out I was using it to get the stricter compiling. Smaug is a nasty beast to clean up and convert over. ;)
26 Aug, 2008, Lobotomy wrote in the 10th comment:
Votes: 0
Yes, yes it is… That's one of the main reasons I stopped using it, and just started over fresh with Socketmud. :thinking:
26 Aug, 2008, kiasyn wrote in the 11th comment:
Votes: 0
SocketMUD actually handles sockets pretty poorly. :/
26 Aug, 2008, Lobotomy wrote in the 12th comment:
Votes: 0
How so?
26 Aug, 2008, Guest wrote in the 13th comment:
Votes: 0
kiasyn said:
SocketMUD actually handles sockets pretty poorly. :/


Indeed it does. So does Smaug and pretty much everything else in the Diku line. Last I looked through SocketMUD that code resembled the same flow and structure as MERC sockets so it didn't surprise me to find that it handled them about as well. Even so, SocketMUD right now is as close to barebones minimum as you'll get. It's far easier to build up from there into what you want than to strip down some gargantuan monster like Smaug or AFKMud into something you want.
26 Aug, 2008, kiasyn wrote in the 14th comment:
Votes: 0
The best handling of sockets I have seen is in Tyche's TeensyMUD… check it out.

Also, for a barebones-socketonly codebase, I would expect want more hooks into the sockets, so I wouldnt have to mess with them directly.
26 Aug, 2008, Lobotomy wrote in the 15th comment:
Votes: 0
I'm confused. What are the two of you speaking of regarding how sockets are poorly handled in Socketmud? It is poor performance or inefficiency, or a lack of fuller features regarding various other aspects of the telnet protocol, like IAC commands, OOB communications, etc - i.e the sockets are bareboned too, compared to others?
26 Aug, 2008, David Haley wrote in the 16th comment:
Votes: 0
The main problem is that the compiler used to silently accept string literals as char*, even though they really should be const char*. The reason is that most OSs will not allow editing of strings in the code's data segment, which is where string literals reside. So, if you ever pass a string literal to a function that edits it – and we've seen this happen a few times in SMAUG – the code will crash. I was going to write more but I realized I've already written a lot of this; see this forum post.
26 Aug, 2008, Lobotomy wrote in the 17th comment:
Votes: 0
DavidHaley said:
The main problem is that the compiler used to silently accept string literals as char*, even though they really should be const char*. The reason is that most OSs will not allow editing of strings in the code's data segment, which is where string literals reside. So, if you ever pass a string literal to a function that edits it – and we've seen this happen a few times in SMAUG – the code will crash. I was going to write more but I realized I've already written a lot of this; see this forum post.

I see.

On a different note, will someone please tell me what's wrong with Socketmud's sockets? :mad:
26 Aug, 2008, David Haley wrote in the 18th comment:
Votes: 0
Lobotomy said:
On a different note, will someone please tell me what's wrong with Socketmud's sockets? :mad:

At least give them a chance to wake up first. :wink:

If they're anything like Merc/Diku/Smaug sockets, then they are not very efficient about how they send out data; instead of using as much bandwidth as available, they regiment data on ticks. Deciding how much data to send out is the OS's job, not the MUD's. Things were probably different last decade, but, well, we're not in the last decade anymore. :wink:
26 Aug, 2008, Guest wrote in the 19th comment:
Votes: 0
David pretty much summed it up. The socket code in SocketMUD is more or less the same as in Diku derivs and carries with it all the inefficiencies of that model along with some of the same bugs with receiving and processing data. It also has a lot of the same problems with handling descriptors associated with those sockets during game updates.

Of all the things that have been updated in MUDs over the years you'd think the core networking code should have received some attention.
26 Aug, 2008, Lobotomy wrote in the 20th comment:
Votes: 0
Samson said:
David pretty much summed it up. The socket code in SocketMUD is more or less the same as in Diku derivs and carries with it all the inefficiencies of that model along with some of the same bugs with receiving and processing data. It also has a lot of the same problems with handling descriptors associated with those sockets during game updates.

Of all the things that have been updated in MUDs over the years you'd think the core networking code should have received some attention.


That's why I'm concerned about knowing the fine details regarding any and all problems with said code. I have no inhibitions about getting in there and fixing it; some of it has been fixed or otherwise augmented from stock in my codebase, in fact, although I don't know for sure if I've fully addressed all the issues. While I appreciate the feedback thusfar, I still feel as though you're being a bit too generic on the matter. More detail on the precise aspects that are flawed and flawed in what way, would be useful.
0.0/32