21 Aug, 2007, Mister wrote in the 21st comment:
Votes: 0
It can be because so much of the code is horribly written. For example, if after changing do_ functions to use const char, it will complain on a call to is_valid_class(argument), if is_valid_class receives a char* (it should receive a const char*).

Also, one_argument signature should be changed to: const char* one_argument( const char*, char* ).

Anyway, I've seen way too many codebases that compile without warnings… until you actually activate warnings, then it's thousands upon thousands of warnings, even very basic ones.

These write-string warnings, I consider them a bug, since the string in do_say(ch, "Die, swine!") is clearly a const, and should be regarded as such.

And this goes further than strings… check this old, trusty function: int get_trust( CHAR_DATA* ch ) which should be changed to receive a const CHAR_DATA instead.

But I still think this discussion is moot, since there is a simple workaround involving adding a single extra parameter to Makefile. If you don't want the compiler to protect you from your mistakes, you are free to do so. I'll continue compiling with -pedantic -Wall -Wextra -Werror :wink:
21 Aug, 2007, Guest wrote in the 22nd comment:
Votes: 0
I don't need to be protected from mistakes that aren't causing me grief. I'm not stupid. I don't compile with zero warnings enabled. This is my current set of warnings:

W_FLAGS = -Wall -Werror -Wformat=2 -Wshadow -Wpointer-arith -Wcast-align -Wcast-qual -Wredundant-decls -Wconversion

So yes, I do stop the compile on receiving warnings from this. Yes, originally it was a supreme investment of time to clean it all up. Some of these tags generated no warnings anyway, which tells me the code was already good.

In my case adding -pedantic generates two additional warnings on code related to dlsym lookups that return perfectly valid results. It just doesn't comply with some strict standard somewhere. Much like when XHTML 1.1 bitches that the target= attribute for a link tag is invalid. Since it's not a real error, I leave that out. Knowingly.

-Wextra generates a bunch of shit about unused arguments and other things, from some of the very same do_fun's that we've been talking about. Not even remotely a problem. So why put up with it?

This whole -Wwrite-strings reeks to me of -Wextra on steroids. A lot of compiler yelling and screaming over nothing. Sure, there are some instances of warnings reported that should be fixed. But they don't NEED to be fixed. Unless you know there's a problem, it's just inconvenient to bother.
21 Aug, 2007, Mister wrote in the 23rd comment:
Votes: 0
Exactly, if a warning bothers you because you know the code is right but the compiler doesn't, by all means hide it. I use -Wno-long-long in my C++ code without feeling any shame. But I've been compiling with -Wwrite-strings since long ago.

Now, if you want a completely bogus and usually unfixable warning, try -Wpadded.
22 Aug, 2007, Tyche wrote in the 24th comment:
Votes: 0
I updated Debian to g++ 4.2 and thought I'd check out this against Murk++.
I only had to change 7 lines to get the code const correct. I expect the bulk of the potential problems vanished with the substitution of c++ strings in most of the Merc code.
Sqlite 3.3.2 already compiles cleanly without warnings on 4.2.

P.S. Interesting. I tried my port of the ancient TinyMud 1.5.4 and the only new warning was…
'the 'gets' function is dangerous and should not be used'
08 Nov, 2007, kremlin wrote in the 25th comment:
Votes: 0
Because no one has mentioned it thus far with regard to the do_ functions, I thought I should post this function from ROM 2.4b6.

/* function to keep argument safe in all commands – no static strings */
void do_function (CHAR_DATA *ch, DO_FUN *do_fun, char *argument)
char *command_string;

/* copy the string */
command_string = str_dup(argument);

/* dispatch the command */
(*do_fun) (ch, command_string);

/* free the string */
08 Nov, 2007, Guest wrote in the 26th comment:
Votes: 0
Not being entirely familiar with how Rom does things, what's the point in using that do_function() function? There are a lot of commands that take the incoming argument and break it up into pieces, altering the original. How does allocating it through str_dup help things?
08 Nov, 2007, Mister wrote in the 27th comment:
Votes: 0
The process of "breaking" the argument into pieces doesn't alter the original.

The problem it tries to solve is similar to the bug in some muds where "do_say" alters the argument if the character is drunk, and do_say is called with static strings sometimes. Make one of those calls with a drunk character and poof.

Basically, do_ functions' argument should be "const char*" instead of just "char*". This do_function function copies the argument to a freely modifiable copy to avoid those issues. A good idea if you are not willing to fix the problem the correct way.
08 Nov, 2007, David Haley wrote in the 28th comment:
Votes: 0
Breaking the argument into pieces isn't supposed to change the original string. The problem is that one_argument doesn't use const. You're just moving a pointer around, you're not modifying what it points to. You get into trouble when you need to actually modify the data, e.g. make the argument lowercase.