Hi. I've just swiched servers (at the begging of my sysadmin), and ran to a small problem. The base compiled just fine on the previous system, but when I moved it to the new machine the following err occurred on compile:
--------------------------------------
Compiling o/websvr.o....
Compiling o/act_comm.o....
Compiling o/act_info.o....
Compiling o/act_move.o....
Compiling o/act_obj.o....
act_obj.c: In function `do_brandish':
act_obj.c:2425: warning: signed and unsigned type in conditional expression
act_obj.c:2430: warning: signed and unsigned type in conditional expression
make[2]: *** [o/act_obj.o] Error 1
----------------------------
I'm using :
gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux)
--------------------------------------
Sysinfo for the machine in question:
Operating system: [ SuSE Linux 8.2 (i586) ]
Host: [ node01.darkseas.net, Kernel: 2.4.20-4GB (i586) ]
----------------------------
Know what caused this/any possible resolution?

Not sure. Not unless SUSE modified the compiler for some bizarre reason. What's on those lines of code for you?

Dont know about the compiler modification.. I've looked, but have been unable to find anything saying so. As for the lines, This is the selection. Dont remember WHICH lines specifically, but I places markers here to show you about where (My shell is down until tommorrow. (Stupid server maintenance ) :
-------------------------------------------------------
case TAR_CHAR_OFFENSIVE:
*line 2425* if ( IS_NPC(ch) ? IS_NPC(vch) : !IS_NPC(vch) )
continue;
break;
case TAR_CHAR_DEFENSIVE:

*line 2430* if ( IS_NPC(ch) ? !IS_NPC(vch) : IS_NPC(vch) )
continue;
break;
case TAR_CHAR_SELF:
if ( vch != ch )
continue;
break;
}

That sounds like perhaps ch is signed, and vch is unsigned, but this shouldn't be... unless one isn't assigned to the CHAR_DATA data type. Hrm. This is just odd.

I mean, it couldn't be an issue with C's compound expressions... right? That should be standard...

Though that line of code escapes me as far as what it does...

Well, you could try this:

if (((IS_NPC(ch)) ? (IS_NPC(vch)) : (!IS_NPC(vch))))

and

if (((IS_NPC(ch)) ? (!IS_NPC(vch)) : (IS_NPC(vch))))

It shouldn't make a difference though... it's just explicitly telling C what's what, which it should already assume.

I'm also curious about the 'prerelease' in the version you gave? Perhaps there's a few issues with this release you have, and you may want to have your system admin check for a newer version of gcc, or go back to using a 'stable' version.

Again, I'm speculating.

Ahh wait *click*

You may also want to check up on the values that the switch case can hold. switch is a conditional statement...

That's all I can see though. those two conditional statements. I mean, unless SuSe doesn't like something in the IS_NPC macro, but then it should kick out an error code from mud.h

It also doesn't make sense that ch or vch could be unsigned, since they're data structures, not integers.

I also checked up on both TAR_CHAR_* and skill_data->target... unless typedef enum is declared unsigned, then I can't figure it out. I know that the target in skill_data is declared a sh_int, which would either be an int or short int, depending on the system.

I'm not familiar with 'enum' though. I just know it's how you make flag structs *G* (Yes, even I am still learning!)

> gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux)

Scary! You're using a pre-release version of gcc 3.3!
Oh well, no guts no glory!

Hmmmmm, I just tried this expecting to get a warning, but... gcc -Wall didn't whine.

#include

typedef enum {
ack = 0,
pfft,
foo,
bar
} e_foo;

int main(void) {
unsigned int a = -1;
e_foo f = pfft;

switch(a) {
case -1: printf("I be broken!
"); break;
case 3: printf("I'm fine
"); break;
};
printf("f is %d
", f);
return 1;
}

First of all, I would have expected gcc to whine about assigning -1 to a, as that would have mapped -1 to 4 billion...

Then, I would have expected case -1 to never come up, yet it does.

At least enums work as they're supposed to! It prints 1.

This is under gcc 3.2 Red Hat linux 8.0 (yeah, I'm at work, leave me alone!)

I *WAS* going to suggest looking at the type of the variable you're switching on to see if that's unsinged, with a signed #define'd label in one of your cases..... but apparently that doesn't matter before noon.

I'm going back to writing perl code before my boss starts asking about the lack of dollar-signs on this screen...

Hrm. Didn't notice the compiler version. SuSE pulled a Redhat 7.3 I see. Bad enough RH did this with 2.96 and raised a stink, now this? Heh. I have no idea what sort of results 3.3 will produce, but if that's a sign of things to come then it looks like the code may need a scrub. Or GCC needs a kick in the ass.

I think it may be the later.
*bonks head on desk*
Yeah, I'm re-installing Fbsd on this thing, even though compaq loves to make it difficult. (plus, this is a good reason to install fbsd

Not the operating system's fault in this case. It was the compiler component, though I imagine attempting to remove it and use a standard stable release would be quite the headache as there may be other things dependent on it.

I would rather change OS's. Didnt want that on it anyway (just had a disk laying around)