12 Feb, 2009, Igabod wrote in the 1st comment:
Votes: 0
I've decided to take it upon myself to clean low4 up a little bit so that people can start a low4 without having to go through all that extra work to make it compile the first time.

My goal isn't to remove any of the bugs or any of the inherent problems with the code, I'm just make it compile cleanly on gcc 4.3.2 and removing the useless files. I removed all the IMC files (around 15 or more) from the code cause this version is way outdated and buggy as hell. I'm not planning on putting a newer version of IMC in cause not everybody will want it in their mud and if they do then let them put it in.

I have already gotten almost all the warnings/errors fixed and will probably have this release ready within the next week or so. I was curious though, if anybody with more coding experience than myself would be willing to look at it before it is released and tell me if I missed anything. I'm not trying to add any features at all, just trying to get it to compile clean since every version of low4 available for download requires a lot of corrections before it will even compile. If somebody such as Tijer or Kavir or someone with their level of experience with this code is willing to take a look, please PM me on here.
16 Feb, 2009, Igabod wrote in the 2nd comment:
Votes: 0
Ok, I've not gotten any response from anybody on this subject, but I thought I'd give a little notice that I'll be releasing this either Tuesday or Wednesday sometime. If anybody wants to look at it and make sure I haven't forgotten to do something before I upload it, please pm me or email me at TheIgabod [At]gmail[D0t]com. I'd really appreciate any input on this before I release it.
16 Feb, 2009, Sharmair wrote in the 3rd comment:
Votes: 0
As you are basically cleaning up the code to compile on a more picky compiler, you might as
well clean it up to compile under g++ (I mean so it will compile on both gcc or g++ here). You
are bound to find more sloppy uses of type and even though you might not use any of the added
features in the compiler, the code will be ready if some user down the line chooses to.

As a side note, I think everyone (using gcc) should do this (and I basically have on most MUDs
I have helped on, even if they were unaware).
18 Feb, 2009, Igabod wrote in the 4th comment:
Votes: 0
You know, that's a good idea, I will do that. I hadn't even thought about g++ since I rarely use it myself.
18 Feb, 2009, Guest wrote in the 5th comment:
Votes: 0
You do need to be aware of one thing if you're going to use g++ 4.3.2. There will be a hell of a lot of issues with const char* stuff going that route. It's not a fix that can be taken lightly or quickly. I'm not sure if the same stuff comes up with just using gcc.
18 Feb, 2009, David Haley wrote in the 6th comment:
Votes: 0
I think there's a compiler flag to turn off those warnings, right? It's not the "right" thing to do, but it would let you go forward without having to trudge through the fairly monumental const fix…
18 Feb, 2009, Kline wrote in the 7th comment:
Votes: 0

Using the bastardized method myself atm just so I can focus on more important issues while I plan how I want to handle the fix.
18 Feb, 2009, Scandum wrote in the 8th comment:
Votes: 0
Getting rid of 'const' all together would be my suggested fix. It's a nice idea in theory, but it doesn't work well in practice.
18 Feb, 2009, David Haley wrote in the 9th comment:
Votes: 0
What? I have found that it works beautifully in practice. How has it not worked for you?

EDIT: in fact, I tend to miss it in languages that don't have it…
18 Feb, 2009, Kline wrote in the 10th comment:
Votes: 0
Even removing const isn't that quick of a fix, proper or not (which I don't agree with doing). Many places call command arguments with do_thing(ch,"hello world") which is already a const string literal.
18 Feb, 2009, David Haley wrote in the 11th comment:
Votes: 0
Making string literals like that non-const is a Very Bad Idea (TM) – there have been a few cases of subtle crashes due to functions messing with string literals. There's really a reason why const exists; guaranteeing the non-modification of string literals is just one.
19 Feb, 2009, Igabod wrote in the 12th comment:
Votes: 0
Ok, well I'll make that a side project to work on here and there. Till then I'll release the gcc 4.3.2 compliant version. Most likely tomorrow.
20 Feb, 2009, Igabod wrote in the 13th comment:
Votes: 0
I've now uploaded the cleaned up code to the repository here. As soon as it is approved I will post a link here.

Also, if you don't want to wait to download it, go to My Homepage and you can download this as well as the original version that I started from.

At the moment there is one more download available, but I'm hoping to add to that in the near future. Please don't mind the boring page, I'm still re-learning html and kinda lazy, the page may change appearance in the coming weeks, but the files will still be available.

[edit to format this post to make it easier to read]

[edit to add]Ok, it has been uploaded now, the addy to download it is http://www.mudbytes.net/index.php?a=file...
20 Feb, 2009, Igabod wrote in the 14th comment:
Votes: 0
Kline said:

Using the bastardized method myself atm just so I can focus on more important issues while I plan how I want to handle the fix.

Where would I put this flag in my makefile? Directly after g++? or after the -O -ggdb? Or maybe someplace else. I tried doing g++ -Wno-write-strings and that resulted in a bunch of const errors so I'm guessing that's not the right place.
20 Feb, 2009, David Haley wrote in the 15th comment:
Votes: 0
You would put it in the cflags. But it won't fix the const warnings – it just changes the behavior of string literals, as I recall. man g++ will tell you for sure.
20 Feb, 2009, Kline wrote in the 16th comment:
Votes: 0
Just somewhere in your cflags; wherever you have -Wall or similar. It should fix the const warnings (fixed mine) as far as not yelling at you for them.

Here's a link about it: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/...
20 Feb, 2009, David Haley wrote in the 17th comment:
Votes: 0
It won't (shouldn't) fix constness in cases that aren't related to string literals. I.e.,

void f(char* c) {


const char* bla;
f(bla); <– const problem, but no string literal
21 Feb, 2009, Guest wrote in the 18th comment:
Votes: 0
Kline, that's a nice link. Seems they may finally have gotten enough angry complaints about making that warning visible with -Wall and had to act on it. That behavior they specify was not the case with 4.3.0 through 4.3.2. Much to the woes of a lot of us here I might add.
21 Feb, 2009, Kline wrote in the 19th comment:
Votes: 0
Samson, so previously it was triggering just with -Wall? That would be horrible indeed. Some day I do intend to fix it, but it's low on my list of priorities, especially with this "just now" cropping up for me since I run Debian who (finally lol) included 4.3 as the default with Lenny now.
21 Feb, 2009, Igabod wrote in the 20th comment:
Votes: 0
I'm not trying to fix anything with this, just suppress the output so that I can see the errors. The const problems can wait till last due to the sheer number of them in the low4 codebase.