050DR3 compile

Dominatus · #1 09-23-2003, 05:16 AM

Anyone else having issues with compiling zone?

I get several errors from client_process.cpp as follows:

client_process.cpp: In member function `int Client::HandlePacket(const
APPLAYER*)':
client_process.cpp:991: warning: comparison is always true due to limited range
of data type
client_process.cpp:1177: warning: comparison between signed and unsigned
integer expressions
client_process.cpp:2150: warning: unused variable `bool cancast'
client_process.cpp:2614: warning: unused variable `TradeRequest_Struct*msg'
client_process.cpp:2783: warning: cast from `const char*' to `char*' discards
qualifiers from pointer target type
client_process.cpp:3376: warning: comparison between signed and unsigned
integer expressions
client_process.cpp:3521: warning: assignment to `int' from `double'
client_process.cpp:3521: warning: argument to `int' from `double'
client_process.cpp:3523: warning: passing `double' for argument 1 of `void
Client::AddMoneyToPP(unsigned int, bool)'
client_process.cpp:3562: warning: assignment to `int' from `double'
client_process.cpp:3562: warning: argument to `int' from `double'
client_process.cpp:3564: warning: passing `double' for argument 1 of `void
Client::AddMoneyToPP(unsigned int, bool)'
client_process.cpp:3514: warning: unused variable `Item_Struct*item2'
client_process.cpp:4145: warning: suggest parentheses around assignment used as
truth value
client_process.cpp:4333: cannot allocate an object of type `const ItemInst'
client_process.cpp:4333: because the following virtual functions are
abstract:
../common/Item.h:308: virtual ItemInst* ItemInst::Clone() const
client_process.cpp:4753: warning: comparison between signed and unsigned
integer expressions
client_process.cpp: In member function `bool
Client::FinishConnState2(DBAsyncWork*)':
client_process.cpp:5136: warning: assignment of negative value `-1' to `int16'
client_process.cpp:5136: warning: argument of negative value `-1' to `short
unsigned int'
client_process.cpp:5140: warning: comparison between signed and unsigned
integer expressions
client_process.cpp:5149: warning: assignment of negative value `-1' to `int16'
client_process.cpp:5149: warning: argument of negative value `-1' to `short
unsigned int'
client_process.cpp:5151: warning: assignment of negative value `-1' to `int32'
client_process.cpp:5151: warning: argument of negative value `-1' to `unsigned
int'
client_process.cpp:5206: warning: unused variable `int bp'
client_process.cpp: In member function `void Client::OPMemorizeSpell(const
APPLAYER*)':
client_process.cpp:6049: warning: comparison between signed and unsigned
integer expressions
make: *** [client_process.o] Error 1

krich · #2 09-23-2003, 06:58 AM

Check my post in the Dev Forum:

http://www.eqemulator.net/forums/viewtopic.php?t=10306

regards,

krich

Trumpcard · #3 09-23-2003, 06:58 AM

Download the latest CVS. THis was fixed yesterday

Merth · #4 09-23-2003, 07:03 AM

The problem is on line 4333 of client_process.cpp. The wrong code may have been pushed out to CVS. Can you verify that the following is found on line 4333:

Code:

if (failproduct!=0) { 
	const Item_Struct* failitem = database.GetItem(failproduct);          
	ItemCommonInst common(failitem);                                  
	PutItemInInventory(SLOT_CURSOR, (ItemInst&)common, true);                        
}

If it's not found, replace the if() statement there with what you see here. We'll work on getting the fix into CVS.

As a side note, I don't believe it makese sense to instantiate an ItemInst on its own. That's why I made it abstract.

Merth · #5 09-23-2003, 07:05 AM

krich, trump - is this the same problem that was encountered yesterday?

Quote:

client_process.cpp:4333: cannot allocate an object of type `const ItemInst'
client_process.cpp:4333: because the following virtual functions are
abstract:
../common/Item.h:308: virtual ItemInst* ItemInst::Clone() const

krich · #6 09-23-2003, 07:18 AM

I suppose that it would be possible that a "return on fail" item could be a book or bag. A bit more code would take care of that potentiality.

regards,

krich

Dominatus · #7 09-23-2003, 07:57 AM

Thanks guys! Much appreciated.

krich · #8 09-23-2003, 08:06 AM

Quote:

krich, trump - is this the same problem that was encountered yesterday?

Yeppers.

regards,

krich

vetoeq · #9 10-02-2003, 07:08 AM

I saw something that made me quite happy with where you guys are going now; it was just one line, but it said much more:

Quote:

Download the lastest CVS. This was fixed yesterday

Source management = a good thing (tm)

-Veto

Trumpcard · #10 10-02-2003, 07:12 AM

As a side project for some of you up and coming developers, can you look into these..

Client::FinishConnState2(DBAsyncWork*)':
client_process.cpp:5136: warning: assignment of negative value `-1' to `int16'
client_process.cpp:5136: warning: argument of negative value `-1' to `short
unsigned int'
client_process.cpp:5140: warning: comparison between signed and unsigned
integer expressions
client_process.cpp:5149: warning: assignment of negative value `-1' to `int16'
client_process.cpp:5149: warning: argument of negative value `-1' to `short
unsigned int'
client_process.cpp:5151: warning: assignment of negative value `-1' to `int32'
client_process.cpp:5151: warning: argument of negative value `-1' to `unsigned
int'

This worries me, when you jam a -1 into a nonnegative type, you end up with really weird outcomes... 4012331212312..... I've mentioned it to Merth, but neither one of us has really had the time to look at it. I started to try and fix the casts, just havent been able to follow through.

Im guessing this is because the first binary bit in an unsigned is one to indicate a negative number, so when its cast to a positive,its intrepreted incorrectly and becomes something abnormally large..

1001 would be -1 in signed, 9 unsigned for instance...

client_process and parser.cpp both have a slew of these warnings, anyone want to take a stab at discovering what the outcome is ?

Bigpull · #11 10-02-2003, 08:34 PM

Usualy it's the local storage with the wrong signedness. Things like the guild id which use abnormaly large storage types, use 0xFF 0xFFFF, thier max value, eg -1. So instead of using 0xFFFF in the code using -1 means you don't have to come back and change it if it changes to say 8bit 0xFF, the 0xFFFF would overflow, or if it goes up in size to 32bit you wind up with 0x0000FFFF which isn't 0xFFFF and then the code is broken but doesn't overflow. So long as the checks are consistant and there aren't any "0" checks..