4$ patch -p1 <../patches/007_antique_OS.diff
patching file HACKLOG
patching file src/Makefile
Hunk #1 FAILED at 1.
1 out of 3 hunks FAILED – saving rejects to file src/Makefile.rej
081010 Quixadhal
0928 Working on removing the args() prototyping and replacing it
with something a bit simpler. In the process, I'm also trying
to clean up the header files and do a very tiny amount of
refactoring to move similar purpose things into similar
places.
TODO - Fix debug malloc support. Apparently this is from a
very old version of dmalloc.
1533 I think a serious refactoring of the file layout is long
overdue. The string handling code seems to be scattered
between recycle.c and db.c. wiznet is in the act_wiz.c
file, yet really it belongs with the rest of the channels
and send_to_char style functions.
I'm at a point where everything compiles, so I will do a
check-in and diff here. Right now, the stuff I've moved
around is pretty minor.
Here's a list of changes:
1 Removed telnet.h – use the system headers, Luke!
2 Removed extern function prototypes from all the source
files.
3 Added function prototypes for every(!) function in the
header files.
4 Created act.h for things related to any of the act_*.c
files.
5 Created special.h to hold the spec_proc stuff.
6 Merged db2.c into db.c
7 Merged magic2.c into magic.c
8 Added new include dependancies, since some things are
now in db.h, act.h, or elsewhere that isn't merc.h
9 As a result of 2-5, the DECLARE_foo() macros aren't
actually used, although they're still there. I don't
like them (it's easier to cut and paste declarations,
and then you aren't hiding how they work).
10 In the process of doing all the above, removed some
of the inconsistent blank lines.. IE: 3 lines between
foo() and foo2(), but 2 lines between foo2() and foo3().
db.c: In function char* str_dup(const char*):
db.c:2681: error: cast from const char* to unsigned int loses precision
cc1plus: warnings being treated as errors
db.c: In function void do_dump(CHAR_DATA*, const char*):
db.c:2816: warning: format %8d expects type int, but argument 4 has type long unsigned int
db.c:2816: warning: format %d expects type int, but argument 6 has type long unsigned int
db.c:2824: warning: format %8d expects type int, but argument 4 has type long unsigned int
db.c:2824: warning: format %d expects type int, but argument 6 has type long unsigned int
db.c:2834: warning: format %8d expects type int, but argument 4 has type long unsigned int
db.c:2834: warning: format %d expects type int, but argument 6 has type long unsigned int
db.c:2846: warning: format %8d expects type int, but argument 4 has type long unsigned int
db.c:2861: warning: format %8d expects type int, but argument 4 has type long unsigned int
db.c:2861: warning: format %d expects type int, but argument 6 has type long unsigned int
db.c:2869: warning: format %8d expects type int, but argument 4 has type long unsigned int
db.c:2869: warning: format %d expects type int, but argument 6 has type long unsigned int
db.c:2873: warning: format %8d expects type int, but argument 4 has type long unsigned int
db.c:2877: warning: format %8d expects type int, but argument 4 has type long unsigned int
db.c:2816: warning: format %8d expects type int, but argument 4 has type long unsigned int
-rwxr-x— 1 quixadhal quixadhal 1023978 Oct 12 02:27 rom++-41
-rwxr-x— 1 quixadhal quixadhal 1013666 Oct 12 02:28 rom++-42
-rwxr-x— 1 quixadhal quixadhal 1034002 Oct 12 02:29 rom++-43
-rwxr-x— 1 quixadhal quixadhal 826106 Oct 12 02:24 rom-34
-rwxr-x— 1 quixadhal quixadhal 970046 Oct 12 02:25 rom-41
-rwxr-x— 1 quixadhal quixadhal 968534 Oct 12 02:25 rom-42
-rwxr-x— 1 quixadhal quixadhal 969435 Oct 12 02:26 rom-43
I added those to the last patch, although a few of them are only allowed for the C language, and that actually varies by compiler version!
I don't think I've ever seen the compiler cough on -Winline, I added that years ago when I was working on a low-CPU power machine and actually tried to inline lots of tiny functions. I don't think it matters, although if it doesn't break anything I'd be tempted to leave it there anyways. The keyword inline doesn't actually appear in any of the code to date.
Okay, that part about variation from compiler version to compiler version concerns me. Do you mean the warnings have different meanings on different versions, or just that not all versions support all warnings?
As for the -Winline, I'd say let's get rid of it. It's not going to do anything for us, and it's just cluttering up an already busy Makefile.
Also, I wonder how much these warnings even work. Consider the ones that I was coping with, the ones caused by -Wcast-qual. According to my documentation, that means "Warn whenever a pointer is cast so as to remove a type qualifier from the target type. For example, warn if a `const char *' is cast to an ordinary `char *'." And that's exactly what statements like "OBJ_DATA *obj1 = (OBJ_DATA *) arg1;" are doing; if gcc 4.1.2 didn't complain about that then the warning is broken in 4.1.2. And no, I don't believe gcc is smart enough to figure out that the variable doesn't really get changed, and I suspect that in your heart of hearts, neither do you.