Ok. Took the plunge and updated the OS here. Which has gcc 4.3 now, so I'm seeing all the lovely new warnings and hard errors. I'll bring the codebase out of hiatus to fix these.
character.h: In member function 'void char_data::WAIT_STATE(int)':
character.h:461: error: conversion to 'short int' from 'int' may alter its value
This stems from the bugfix for the old UMAX macro in which the macro was redirected to a function. That function, along with UMIN and URANGE, became these:
int umin( int check, int ncheck )
{
if( check < ncheck )
return check;
return ncheck;
}
int umax( int check, int ncheck )
{
if( check > ncheck )
return check;
return ncheck;
}
int urange( int mincheck, int check, int maxcheck )
{
if( check < mincheck )
return mincheck;
if( check > maxcheck )
return maxcheck;
return check;
}
What the compiler is now complaining about is that the "wait" value, which is usually ch->wait, is a short integer. That's being passed to the new umax() function which is taking normal integers as arguments. The function in character.h where the problem arise from is this:
void WAIT_STATE( int npulse )
{
( wait = UMAX( wait, ( is_immortal( )? 0 : npulse ) ) );
}
Where, again, "wait" is ch->wait. The simple solution is to change the definition of ch->wait to an int, but the long term solution is to fix the umin(), umax(), and urange() functions to accept multiple types. My preference would be for a template to handle this rather than making dozens of versions of these to account for all the different number types that exist. But I'm not sure how to do that.
character.h:608: error: declaration of 'short int char_data::map'
/usr/include/c++/4.3/bits/stl_map.h:92: error: changes meaning of 'map' from 'class std::map<int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<int>, std::allocator<std::pair<const int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >'
This one is easy. Find:
short map; /* Which map are they on? - Samson 8-3-99 */
Change to:
short cmap; /* Which map are they on? - Samson 8-3-99 */
The downside is this will create a zillion more compiler errors that will need to be fixed because ch->map will no longer exist. They'll just need to become ch->cmap etc. instead. Long tedious process, but apparently necessary now.
In file included from act_comm.cpp:30:
mud.h: In function 'char* bitset_string(std::bitset<_Nb>, const char**)':
mud.h:1375: error: there are no arguments to 'strlen' that depend on a template parameter, so a declaration of 'strlen' must be available
mud.h:1375: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
Gah. This reeks of assholery on GNU's part. Solveable by adding
#include <cstring>
to the include list in mud.h, but damn them, this is going to bloat up the binary file :/
The rest of the stuff in that pastebin looks solveable in similar manners. Somewhere along the way one of the included heade files AFKMud calls up must have dropped the internal include for stdlib, which is going to make it necessary for me to do that explicitly now.
Top Posters
Top Uploaders
increasing output width
Users Online
Stats
Related Links