25 Feb, 2011, Arkanfel wrote in the 1st comment:
Votes: 0
:~/MUD/merc22sands/src$ make
gcc -c -O -Wall -g3 act_comm.c
gcc -c -O -Wall -g3 act_info.c
gcc -c -O -Wall -g3 act_move.c
gcc -c -O -Wall -g3 act_obj.c
gcc -c -O -Wall -g3 act_wiz.c
gcc -c -O -Wall -g3 comm.c
gcc -c -O -Wall -g3 const.c
gcc -c -O -Wall -g3 db.c
gcc -c -O -Wall -g3 fight.c
gcc -c -O -Wall -g3 handler.c
gcc -c -O -Wall -g3 interp.c
gcc -c -O -Wall -g3 magic.c
gcc -c -O -Wall -g3 mob_commands.c
gcc -c -O -Wall -g3 mob_prog.c
mob_prog.c: In function mprog_do_ifchck:
mob_prog.c:373: warning: overflow in implicit constant conversion
mob_prog.c:375: warning: overflow in implicit constant conversion
mob_prog.c:378: warning: overflow in implicit constant conversion
mob_prog.c:381: warning: overflow in implicit constant conversion
gcc -c -O -Wall -g3 save.c
gcc -c -O -Wall -g3 special.c
gcc -c -O -Wall -g3 update.c
rm -f merc
gcc -o merc act_comm.o act_info.o act_move.o act_obj.o act_wiz.o comm.o const.o db.o fight.o handler.o interp.o magic.o mob_commands.o mob_prog.o save.o special.o update.o -O -g3 -lcrypt
:~/MUD/merc22sands/src$

I am looking forward to get this fixed. Any help would be appreciated!
25 Feb, 2011, oenone wrote in the 2nd comment:
Votes: 0
It's not an error, it's just a couple of warnings.

You should have a look at the lines mentioned by the compiler. (Why do I even have to tell you this?)
25 Feb, 2011, Arkanfel wrote in the 3rd comment:
Votes: 0
thank you brother, i figured out that i should give it a try to 2.1 with no mobprogs. =(..
i really love Merc. It is small and not overwhelming like other distros.
25 Feb, 2011, Zeno wrote in the 4th comment:
Votes: 0
It compiled successfully.
26 Feb, 2011, Arkanfel wrote in the 5th comment:
Votes: 0
ahh =(
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
could that be a problem zeno?
26 Feb, 2011, Runter wrote in the 6th comment:
Votes: 0
What problem? I think the other posters are telling you that the compilation was a success and other than a few warnings there is no obvious problem here.
26 Feb, 2011, Vigud wrote in the 7th comment:
Votes: 0
Run-time problem, obviously.
26 Feb, 2011, Runter wrote in the 8th comment:
Votes: 0
Vigud said:
Run-time problem, obviously.


And how is that "obvious?" While you're divining the problem I'll wait for the poster to actually post info on what is wrong.
26 Feb, 2011, Vigud wrote in the 9th comment:
Votes: 0
Implicit conversion may change a value, which can be a problem. Isn't it obvious?

The function returns its value in an "unsigned char" object, which generally is shorter than int. Since type of both ch->affected_by and 262144 is int,
((ch->affected_by) & (262144))
"returns" an int (wider than unsigned char) and you try to return an int in a function that returns unsigned char.

It should be:
return IS_AFFECTED( mob, AFF_CHARM ) ? 1 : 0;
instead.
26 Feb, 2011, Arkanfel wrote in the 10th comment:
Votes: 0
Wow Vigud,

Thank you that fixed it. I'd appreciate it. Thanks for your time!
26 Feb, 2011, Runter wrote in the 11th comment:
Votes: 0
Vigud said:
Implicit conversion may change a value, which can be a problem. Isn't it obvious?


Nope. Wasn't at all obvious. He didn't even describe the problem other than to show a compile with warnings. It's still unclear as to if he wanted warnings to go away or if there was actually an "obvious runtime" error. I guess you went and found the codebase he is using and found those lines. *shrug* I prefer people actually post the needed information and code to help them.

And that starts with clearly defining a problems domain.
26 Feb, 2011, Vigud wrote in the 12th comment:
Votes: 0
A warning that mentions overflow is obviously a problem to any half-decent C programmer. Always. Obviously. I mean it.
26 Feb, 2011, Runter wrote in the 13th comment:
Votes: 0
Vigud said:
A warning that mentions overflow is obviously a problem to any half-decent C programmer. Always. Obviously. I mean it.


:rolleyes:
26 Feb, 2011, David Haley wrote in the 14th comment:
Votes: 0
How is it obvious that there is a runtime problem when only a compile-time problem has been discussed?

Yes, it is obvious that those warnings could cause problems… but nobody said that there actually were problems at runtime…

What was "fixed" here was the compile warning, not a runtime problem. A potential runtime problem, perhaps, but there is no manifested actual problem here, and that is, well, "obvious". :rolleyes:
26 Feb, 2011, Zeno wrote in the 15th comment:
Votes: 0
We never even saw the lines either.
01 Mar, 2011, Rarva.Riendf wrote in the 16th comment:
Votes: 0
May or may not be a problem at runtime, it only depends of what is actually done.
Two solutions:
-ignore it, and risk that you can ACTUALLY get an overflow if you change a formula somewhere without checking you are still within the variable range.
-fix it where it belongs (if you do not need an int, use a sh_int an vice versa..) (and you should ALWAYS comments any formulas explaining why it cannot raise very high value (or low)) (the very fact to comment them usually makes you discover you may not have thought of all the test cases).
01 Mar, 2011, David Haley wrote in the 17th comment:
Votes: 0
Nobody is saying that the warning is completely harmless… what is being disputed is the assertion that there obviously was an actual runtime problem. :smile:
01 Mar, 2011, Rarva.Riendf wrote in the 18th comment:
Votes: 0
David Haley said:
Nobody is saying that the warning is completely harmless… what is being disputed is the assertion that there obviously was an actual runtime problem. :smile:

I am totally agreeing with you on that, but was just explaning to the first poster what he should do when having these kind of warnings. Easy to put long (as an example) everywhere, but you should not.
01 Mar, 2011, Vigud wrote in the 19th comment:
Votes: 0
#include <stdio.h>

typedef unsigned char bool;

#define AFF_HOLD 64
#define AFF_CHARM 262144

#define IS_SET(flag, bit) ((flag) & (bit))
#define SET_BIT(var, bit) ((var) |= (bit))
#define IS_AFFECTED(ch, sn) (IS_SET((ch), (sn)))


bool ischarmed(int ch)
{
return IS_AFFECTED(ch, AFF_CHARM);
}

bool proper_ischarmed(int ch)
{
return IS_AFFECTED(ch, AFF_CHARM) ? 1 : 0;
}

int main(int argc, char **argv)
{
bool a, b;
int ch = 0;

SET_BIT(ch, AFF_HOLD);
SET_BIT(ch, AFF_CHARM);

a = ischarmed(ch);
b = proper_ischarmed(ch);

fprintf(stderr, "David Haley thinks that the char is %scharmed.\n", a ? "" : "not ");
fprintf(stderr, "The truth is that the char is %scharmed.\n", b ? "" : "not ");

return 0;
}
01 Mar, 2011, David Haley wrote in the 20th comment:
Votes: 0
Yes – you found a potential runtime problem. Maybe you can tell us where we said that there was no possible problem?

I'm not sure why you feel it necessary or constructive to get personally snippy.
0.0/39