Sadly, my coding port does not use the same compiler as my game port. So I have commited code which tested and compiled flawlessly on one but is spitting out quite a few of the following warnings…( I had to change the get_hit and get_max_hit macros for the new code)

Any advice would be appreciated…

db.c:2642: warning: use of conditional expressions as lvalues is deprecated
db.c:2642: warning: use of cast expressions as lvalues is deprecated

The line in db.c is this:

GET_HIT(mob) = GET_MAX_HIT(mob);


#define GET_HIT(ch) (IS_MOB(ch) ? (ch)->mob_data.hit : (ch)-> points.hit)

#define GET_MAX_HIT(ch) ((IS_MOB(ch) ? (ch)->mob_data.max_hit : (ch)->points.max_hit))

I've done some research on google and this is what I came up with…

warning: use of cast expressions as lvalues is deprecated

Solution: This occurs when you cast the lvalue (left side) instead of casting the rvalue (right value). For example:

Incorrect:
(void *) x = y;
Correct:
x = (char *)y;

What are you trying to do? I don't think you can set a macro like that in the code.

[EDIT] Logically, that actually would work, so nevermind. Have you tried doing it normally without using the macros as a test?

Increased the max hitpoints for mobs over 32k. So basically I pointed the max_hp for npcs to a different spot than pcs…

if (IS_MOB(mob))
mob->mob_data.hit = mob->mob_data.max_hit;
else
mob->points.hit = mob->points.max_hit;

That worked perfectly, thanks.

I just wonder if there is an easier way to fix 50+ of the same warnings other than to check each one at a time:)

Is there a reason the macro is not working?

Maybe I shouldn't ask, but why would your dev port use a different compiler than your game port?

It's a situation that could come up if your dev port is on another server. Or even on your home machine. Not every host allows people to use up the space necessary for running a development port :)

Samson is correct(although not the reason for…), our coding port is on a seperate machine. I am seeing what I can do to use the same compiler on both, as this situation was/is very frustrating.

I've received notice that our host location may have space available soon if anyone is searching for a dedicated server for their game. We have been hosted here almost a year and have not had one complaint yet.
http://esecuredata.com/default.aspx

Semi-off topic - That host looks like a hell of a deal for what you get. If we ever find ourselves in need of something more than what we have that's definitely going to be on the short list of places to consider!

I'll be honest, we were skeptical in the beginning. Usually if something looks too good to be true it is. A year has passed, no problems, no downtime, no lag, etc.

And you can't beat the cost for the machine, anywhere else we are talking 3-4x the price per month.

Regarding different compiler versions
I really hadn't thought about the possibility of running the dev port on another machine like that, but I can see where it makes sense that if you're not hosting yourself you might save money by hosting the dev port on your own and only running it when you and your staff need it.

Regarding hosting through http://esecuredata.com/default.aspx
They do look like a pretty nice hosting service, even offering windows hosting (which is a real plus for folks looking to run a SmaugWiz or others windows based mud under a host), but the TEMPORARILY SOLD OUT on their page is a big daunting… :sad: (Lucky for me, I host myself so I don't need hosting services, but I do know of someone who is looking at this point.)

Well it is working…now The problem is that it is not ANSI/ISO standard C. GNUisms are being dropped from the gcc compiler. Well in this case, it's something that was valid in the original Kerningham and Ritchie C that was never accepted into the ANSI standard. Perhaps it will be dropped in 4.2-3 release. The warnings are just that, warnings. The reason it's not valid is it violates C's notion of code sequence points. The is the order of execution of the lvalue side of the code in question is undefined by the standard.

EDIT: Sorry I should have said the lvalue expression is ONLY valid if the types are the same, AND is NOT modified by the rvalue expression.

I added a set_hit and set_max_hit function and it seems to do the job. However fixing almost 200 warnings in the code was not very enjoyable. I will think twice the next time this newbie coder decides to change a sh_int to long.

Thanks again,
Splork

Tyche:
When researching that warning, I came across a website(and no I don't have the address handy :-)) that says the next release of the compiler we use will report that warning as an error.

Here's another example which you can find in a lot of old C code:

main() {
int i = 0;
int a[5];
int b[5] = {1,2,3,4,5};
while (i<5)
  a[i++] = b[i];
}

$ gcc lval.c -Wall
lval.c:1: warning: return type defaults to `int'
lval.c: In function `main':
lval.c:6: warning: operation on `i' may be undefined
lval.c:7: warning: control reaches end of non-void function