In this scope argument is type const char* instead of char* as Runter pointed out. It sounds like this project is just in C? C++ has an overloaded function for strstr(char * str1, const char * str2) as it's parameter list.

Not sure where you're at as far as upgrading to g++, but it might be worth looking into.If thats not an option you will need to take a different approach.

I'm not sure. I never had this error with cygwin, but I compile this project with g++

Different compiler versions. The latest cygwin g++ is 4.3.4 and produces a warning that the conversion from const char * to char * will be deprecated.I think g++ 4.4.x versions flag it as an error now.The latest VisualC++ compiler also flags it as an error.

Anything which is declared as "const" is treated as "constant" or "unchanging" by the compiler. It allows it to do optimizations that assume the value of that variable on entry to the function doesn't change by the time the function exits (however that happens). Since DikuMUD code was written before compilers generally did such things, in many cases things ended up declared "const" but then modified anyways, since the compiler let them get away with it.

In your case, the library function strstr() changes the argument passed to it during processing (It puts NULL bytes into the string as it goes, handing you back substrings). Since your argument is declared const, you can't do that.

To work around it (and you'll need to do a LOT of this in any Dikurivative that hasn't already done it for you), you need to make a temporary copy of your string and do your parsing on it. You can also try to trick the compiler by declaring a "char *" and later setting it to point to the same memory of the "const char *", but if the compiler realizes you did this, you're back to square one.

Anything which is declared as "const" is treated as "constant" or "unchanging" by the compiler. It allows it to do optimizations that assume the value of that variable on entry to the function doesn't change by the time the function exits (however that happens). Since DikuMUD code was written before compilers generally did such things, in many cases things ended up declared "const" but then modified anyways, since the compiler let them get away with it.

In your case, the library function strstr() changes the argument passed to it during processing (It puts NULL bytes into the string as it goes, handing you back substrings). Since your argument is declared const, you can't do that.

To work around it (and you'll need to do a LOT of this in any Dikurivative that hasn't already done it for you), you need to make a temporary copy of your string and do your parsing on it. You can also try to trick the compiler by declaring a "char *" and later setting it to point to the same memory of the "const char *", but if the compiler realizes you did this, you're back to square one.

Good luck!

This problem has nothing whatsoever to do with Diku code. They wrote Diku in C and not C++.

Fact. The do_pmote function was introduced in ROM.Fact. ROM was written in C, not C++. Fact. The do_pmote function the poster listed compiles cleanly in modern ANSI-99 standard C.[1]Fact. The RaM project converted ROM from C to C++Fact. The RaM project authors are the sole source of the bug the poster posted.Fact. Neither the Diku team, Merc team nor ROM team are responsible for this bug. Fact. I provided the poster with a fix.

Fact: I was trying to explain *WHY* the const char * issue would likely appear again, not just hand-wave a fix at the OP.Fact: I didn't see any mention of RaM until Tyche mentioned it.Observation: Tyche has a rather painful stick lodged in a place that makes sitting down a mite uncomfortable.

I had already explained that I misread strstr() as strtok(), and I maintain that if you're mucking about with string functions from libc, you are indeed using C, even if you're ALSO using C++. Anything else you feel like bitching about today?

A Red Herring is a fallacy in which an irrelevant topic is presented in order to divert attention from the original issue. The basic idea is to "win" an argument by leading attention away from the argument and to another topic. This sort of "reasoning" has the following form:

1. Topic A is under discussion. 2. Topic B is introduced under the guise of being relevant to topic A (when topic B is actually not relevant to topic A). 3. Topic A is abandoned.

This sort of "reasoning" is fallacious because merely changing the topic of discussion hardly counts as an argument against a claim.

1. Topic A is the poster's problem, his code being flagged with an error while using strstr(). 2. Topic B was introduced by quixadhal, "Since DikuMUD code was written before compilers generally did such things, in many cases things ended up declared "const" but then modified anyways, since the compiler let them get away with it."

As I have illustrated, the laxity of the DikuMud and derivative coders have absolutely nothing to do with the problem the poster posted. As I have also shown, the problem is in fact entirely due to the differences between C and C++.

3. To all appearances, Mr Haley would like to abandon discussion of the poster's problem and the solution in order to discuss Topic B. He even takes it one step further by boldly declaring that actual discussion of poster's problem and solution to be a "red herring".

I think he's either ignorant or a troll.But in order to avoid further arguments I'd recommend the poster implement Mr. Haley's solution.

Fact: I was trying to explain *WHY* the const char * issue would likely appear again, not just hand-wave a fix at the OP.Fact: I didn't see any mention of RaM until Tyche mentioned it.Observation: Tyche has a rather painful stick lodged in a place that makes sitting down a mite uncomfortable.

I had already explained that I misread strstr() as strtok(), and I maintain that if you're mucking about with string functions from libc, you are indeed using C, even if you're ALSO using C++. Anything else you feel like bitching about today?

This problem is clearly caused by "laxity" in understanding the differences between C and C++ . The poster should be prepared as these issues will likely appear again. No I really don't think it all productive in assigning blame or bashing the previous authors (i.e. Diku, Merc, ROM) for problems introduced by RaM.

A Red Herring is a fallacy in which an irrelevant topic is presented in order to divert attention from the original issue. The basic idea is to "win" an argument by leading attention away from the argument and to another topic. This sort of "reasoning" has the following form:

1. Topic A is under discussion. 2. Topic B is introduced under the guise of being relevant to topic A (when topic B is actually not relevant to topic A). 3. Topic A is abandoned.

This sort of "reasoning" is fallacious because merely changing the topic of discussion hardly counts as an argument against a claim.

1. Topic A is the poster's problem, his code being flagged with an error while using strstr(). 2. Topic B was introduced by quixadhal, "Since DikuMUD code was written before compilers generally did such things, in many cases things ended up declared "const" but then modified anyways, since the compiler let them get away with it."

As I have illustrated, the laxity of the DikuMud and derivative coders have absolutely nothing to do with the problem the poster posted. As I have also shown, the problem is in fact entirely due to the differences between C and C++.

3. To all appearances, Mr Haley would like to abandon discussion of the poster's problem and the solution in order to discuss Topic B. He even takes it one step further by boldly declaring that actual discussion of poster's problem and solution to be a "red herring".

I think he's either ignorant or a troll.But in order to avoid further arguments I'd recommend the poster implement Mr. Haley's solution.