Actually, you might have it there. The newer compiler might be smart enough to realize it's just looking at the value, not changing it. Thus it would complain further down the road if the value got modified…

That's part of the reason I wanted everyone to specify their development platform. g++ 4.1.2 compiled that without warnings. In fact, you might notice the -Werror flag I added which treats any warnings as full errors. That's been a debatable issue, but unless we can't get a superset of patches that don't produce warnings on *most* common compilers, I like it as the default.

As to making more things const…. yes, it would be a good thing to do. I actually removed const in a couple places just to clear up the warnings, because I know when this stuff was originally coded, nobody was really using good coding standards *grin*. Back in the early 1990's, it was perfectly acceptable for functions to have side effects, although they did suggest you document them in the headers. A few years of supporting that kind of code led us to realize that, no, side effects really are bad.

Ideally, if MacGregor could upload his patches (or provide a link) against what I did, we can see if the combined set still works clean against 4.1.2 as well.

I would say that we should NOT bother supporting anything OLDER than gcc 3.4.x. I think there's a limit on how much backwards compatibility is sane, and 3.4.4 was released in March of 2005 (3.4.0 was May 2004). That's not to say it wouldn't be nice if it'd compile on gcc 2.95 under SunOS 4.1 – but let's not bang our heads against that wall, we might get asbestos poisoning.

Oh yeah, come to think of it… did the older g++ accept all those extra warning flags I added? It occured to me that some of them might have been added more recently.

Compilers not implementing C++98 is probably not worth wasting breath on.

Okay, I'll finish the cleanup; I'll have to upload the patch and/or changed files here. I'll update your HACKLOG, or would you prefer I put my changes in a separate log?

As for minimum version to support, I should mention that my mud is running on a commercial server that has gcc version 3.2.3 installed. After I get my hack done I'll ship it over there and see if it flies.

Hey, I can dig out an old 486 with kernel version 2.0.8 and ecgs 2.71 or something like that :biggrin:

And no, 3.4.6 didn't have any problems with your warning flags.

We're starting up the round-table discussion on the server in a few minutes, if anyones interested in joining the project.

Well, I'd argue that in many cases, side effects are perfectly fine, as long as they are predictable side effects. Non-obvious side effects are indeed pretty bad. I'm assuming that by 'side effect' you are using the meaning that pure functional programming uses.

Okay, messing around with compiling this with g++ 3.4.6, I get these warnigns as I posted earlier:

# comm.c: In function `void act_new(const char*, CHAR_DATA*, const void*, const void*, int, int)':
# comm.c:2443: warning: cast from `const void*' to `CHAR_DATA*' discards qualifiers from pointer target type
# comm.c:2444: warning: cast from `const void*' to `OBJ_DATA*' discards qualifiers from pointer target type
# comm.c:2445: warning: cast from `const void*' to `OBJ_DATA*' discards qualifiers from pointer target type
# comm.c:2512: warning: cast from `const void*' to `char*' discards qualifiers from pointer target type
# comm.c:2513: warning: cast from `const void*' to `char*' discards qualifiers from pointer target type
# comm.c:2536: warning: cast from `const void*' to `char*' discards qualifiers from pointer target type
# comm.c:2542: warning: cast from `const void*' to `char*' discards qualifiers from pointer target type

Fixing the first seven is pretty straightforward, but the seventh is a bugger. The offending line is this:

one_argument( (char *) arg2, fname )

where the char * cast needs to be changed to const char *, with the appropriate changes made to one_argument(). Now, since one_argument() returns its first argument (sort of), it will also have to return a const char *. This in turn means that every do_function will have to be changed to take a const char * second argument, instead of a char *, since one_argument() is used to pick off the command itself from the user's command line.

So, umm, what other problems will this lead to?

Ah, the hornet's nest. Once you reach having to do all the do_fun stuff then you're going to be going down a long and tedious road that David I'm sure can tell you is a lot of work. I know it was quite the pain when I finalized my const* conversion in AFKMud and I'd already converted the do_fun's to std::string.

Ok, this really isn't pertinent to our discussion, but it happend IN my ROM fixup directory…
I think I found a bug in the mdadm software raid code…. :(

quixadhal@andropov:~/rom$ ls -al fixup_081004
total 0
?——— ? ? ? ?            ? fixup_081004/.
?——— ? ? ? ?            ? fixup_081004/..
?——— ? ? ? ?            ? fixup_081004/HACKLOG
?——— ? ? ? ?            ? fixup_081004/MudBytes
?——— ? ? ? ?            ? fixup_081004/README
?——— ? ? ? ?            ? fixup_081004/README.rom
?——— ? ? ? ?            ? fixup_081004/README.version
?——— ? ? ? ?            ? fixup_081004/area
?——— ? ? ? ?            ? fixup_081004/doc
?——— ? ? ? ?            ? fixup_081004/gods
?——— ? ? ? ?            ? fixup_081004/log
?——— ? ? ? ?            ? fixup_081004/player
?——— ? ? ? ?            ? fixup_081004/src
quixadhal@andropov:~/rom$ sudo -s
root@andropov:~/rom# ls -al fixup_081004
total 60
drw-r–r– 8 quixadhal users 4096 Oct  3 23:18 .
drwxr-xr-x 8 quixadhal users 4096 Oct  5 19:55 ..
-rw-r—– 1 quixadhal users 8184 Oct  3 23:18 HACKLOG
-rw-r—– 1 quixadhal users  132 Mar  5  2007 MudBytes
-rw——- 1 quixadhal users 4873 Sep  7  1995 README
-rw——- 1 quixadhal users 1243 May 27  1998 README.rom
-rw——- 1 quixadhal users   24 May 29  1998 README.version
drwx—— 2 quixadhal users 4096 May 29  1998 area
drwx—— 2 quixadhal users 4096 May 27  1998 doc
drwx—— 2 quixadhal users 4096 Oct 23  1995 gods
drwx—— 2 quixadhal users 4096 Oct  9  1995 log
drwx—— 2 quixadhal users 4096 Mar  5  2007 player
drwx—— 2 quixadhal users 4096 Oct  3 23:22 src

and then off in /var/log, I see:

daemon.log.0:Oct  5 01:06:01 andropov mdadm: RebuildStarted event detected on md device /dev/md1
daemon.log.0:Oct  5 01:06:15 andropov mdadm: RebuildStarted event detected on md device /dev/md6
daemon.log.0:Oct  5 01:06:15 andropov mdadm: RebuildFinished event detected on md device /dev/md1
daemon.log.0:Oct  5 01:07:15 andropov mdadm: Rebuild20 event detected on md device /dev/md6
daemon.log.0:Oct  5 01:08:15 andropov mdadm: Rebuild60 event detected on md device /dev/md6
daemon.log.0:Oct  5 01:09:09 andropov mdadm: RebuildStarted event detected on md device /dev/md9
daemon.log.0:Oct  5 01:09:09 andropov mdadm: RebuildFinished event detected on md device /dev/md6
daemon.log.0:Oct  5 01:14:09 andropov mdadm: Rebuild20 event detected on md device /dev/md9
daemon.log.0:Oct  5 01:19:09 andropov mdadm: Rebuild40 event detected on md device /dev/md9
daemon.log.0:Oct  5 01:24:09 andropov mdadm: Rebuild60 event detected on md device /dev/md9
daemon.log.0:Oct  5 01:29:09 andropov mdadm: Rebuild80 event detected on md device /dev/md9
daemon.log.0:Oct  5 01:34:28 andropov mdadm: RebuildFinished event detected on md device /dev/md9
daemon.log.0:Oct  5 01:34:28 andropov mdadm: RebuildStarted event detected on md device /dev/md8
daemon.log.0:Oct  5 01:34:47 andropov mdadm: RebuildFinished event detected on md device /dev/md8
daemon.log.0:Oct  5 01:34:47 andropov mdadm: RebuildStarted event detected on md device /dev/md5
daemon.log.0:Oct  5 01:35:47 andropov mdadm: Rebuild20 event detected on md device /dev/md5
daemon.log.0:Oct  5 01:36:47 andropov mdadm: Rebuild40 event detected on md device /dev/md5
daemon.log.0:Oct  5 01:37:47 andropov mdadm: Rebuild60 event detected on md device /dev/md5
daemon.log.0:Oct  5 01:38:44 andropov mdadm: RebuildStarted event detected on md device /dev/md7
daemon.log.0:Oct  5 01:38:44 andropov mdadm: RebuildFinished event detected on md device /dev/md5
daemon.log.0:Oct  5 01:39:44 andropov mdadm: Rebuild80 event detected on md device /dev/md7
daemon.log.0:Oct  5 01:39:57 andropov mdadm: RebuildFinished event detected on md device /dev/md7

According to the log, mdadm rebuilt everything… yet clearly not quite.
Fortunately, the patch file is fine, and deleting the offending directory seems to have worked.

Long story short, my hard drive crashed early this year, but it was the controller board that fried. So,
I swapped a new board into it, and added a second drive, then converted them to a software RAID 1
array. It was fun converting a running linux box to a raid system on the fly. :)

Flawless and quite a bit faster disk I/O too, up until this little event.

REMEMBER TO DO BACKUPS KIDS!

Okay, I've uploaded a version that compiles cleanly with both 3.4.6 and 3.2.3, both gcc and g++, in the RaM section, the file name is fixup_081006.tar.bz2. I also uploaded a diff against CleanedG++Rom24b6.tar.gz (fixup_081006.diff.txt).

After getting it to compile with g++ I tried it with gcc. I wasn't surprised to find that bool was no longer defined, but I was surprised at some of the other warnings I got; a couple more shadowed names and even a "suggest braces to avoid ambiguous 'else'".

BTW Quixadhal, I took a look at the warnings you've enabled. Some of them are already enabled by -Wall, specifically:

-Wformat
-Wformat-security
-Wmissing-braces
-Wparentheses
-Wchar-subscripts
-Wreturn-type
-Wswitch
-Wunused

and I am really curious as to why your compiler missed the casts from const to non-const with -Wcast-qual enabled.

Cool, I'll grab those and make sure they still work in 4.1.2, and hopefully my testing VM with 4.3.x as well. ;)

I should note that some of those flags are ones that were NOT part of -Wall when I made my list, probably about 4 years ago…. I tried compiling with 2.95 and discovered that -Wmissing-format-attribute didn't even exist back then. Some of them probably were, but it doesn't hurt to emphatically turn them on I guess.

If 4.3.x suddenly finds those casts again, I'll suggest it was a bug introduced in the 4.0 series that didn't get fixed until now. If not, I'll stand by my original guess that the newer compiler is clever enough to figure out the memory pointed to never gets written, and therefore is still const safe anyways. Hey, that optimism thing is hard! :)

As for bool…. I supppose somewhere we can track down the #define for it and make it automatic if the compiler is not C++. If I remember right, C++ uses "true" and "false" – lowercase, so we can easily make #defines for them as well.

Thanks! We'll get this guy polished up yet. Once we're in SVN, it'll be easier to generate patches too.

Here's what I already stuck near the top of merc.h:

/*
 * Accomodate both gcc and g++
 */
#if !defined __cplusplus
typedef unsigned char   bool;
#endif

so we're good as far as that goes. It might not hurt to add #define false 0 and #define true 1 inside that ifdef while we're at it, or better yet, #define false FALSE and #define true TRUE :smile: Oh, and to be uber anal, we should wrap them in parens.

By the way, a trick if you're going to be doing several compiles with both gcc and g++: comment out the first line of the Makefile (CC = gcc/g++). Then type:
make clean && CC=gcc make
or make clean && CC=g++ make
depending on which way you want to compile. Easier than re-editing the Makefile or make -f gcc-makefile or whatever. Or not.

I'm happy to report that the code continues to work under gcc/g++ 4.1.2 as well. I plan to see if I can get it to behave in gcc 2.95, which I would declare the absolute oldest we could imagine supporting – anything older pokes into the pre-unification days of very bad mojo. I have a VM with 4.3.2 installed and ready for const char * hell, later in the week. :devil:

I would also like to begin the removal of all the ancient OS #ifdefs, if that's ok with folks. We'd agreed that supporting things like pre-OS X macintosh, Amiga, AIX, and other such monstrosities isn't worth the added complexity and manpower.

I did a quick patch to enable the -Wredundant-declarations flag, and strip out a few places where system calls were hand-prototyped as well. That's a Bad Practice(TM), because if the OS changes their prototype, now you're trying to override it with an incorrect one. Any function that isn't defiend BY our codebase needs to be included by the system headers, not hand-cobbled.

If it's OK with you MacGregor, I merged your hacklog in with mine. I figured it would be easier to keep things in chronological order that way, especially if it starts getting extended by more than just the two of us.

I'll upload the mini-patch tonight (it's a patch against the last patch… not a full patch against ROM). I'm used to using incremental patches, and it usually makes it easier to apply around customized code.

I don't know how formal or fancy we want our SVN to be. We could just check in changes directly and only branch if someone wants to try something BIG – or we could have each developer fork a branch and let them be merged after someone else's eyes have looked it over? Both ways work, I'm easy. :)

I'd very strongly suggest that you use a distributed version control system like bzr, git, or mercurial. Except for git, the interface is basically the same as what you already know, but it makes working on several copies of the code a lot easier.

That's good to hear, Quix. I actually agree we should give it a shot with 2.95. If we can support that without a herculean effort, I believe we should. However if it turns out to be a big deal to do it, then I wouldn't worry about it.

Removing all those system-specific #defines, I'd say go for it. Unless someone actually has AIX or an Apollo or Solaris or whatever and can actually test it. If we can't test it then it really shouldn't be there. As for the library routines and system calls, we definitely shouldn't be declaring them ourselves. Go ahead and axe them. As you say, it's a Bad Practice(TM).

As for warnings, good idea with the -Wredundant-declarations to clean out stuff like that. Speaking of warnings, I meant to toss a couple in myself, which I use on my own mud, but I'd forgotten to. They are -Wuninitialized, -Wmissing-prototypes, -Wstrict-prototypes and -Wmissing-declarations. And, uhh, do we really need -Winline? Do we *care* if the compiler is unable to inline a function?

No problems with merging my hacklog with yours. I'd asked you previously if you preferred I did that; guess it got overlooked. As for SVN, I'm easy to get along with in that respect too.

Speaking of which, David, could you expound on why bzr/git/mercurial would be better for us? I'm not familair with any of them; I'd used svn a bit on my own and cvs at work. Educate me, please.

In DVCS, there is no hard-coded notion of a "central branch". Every check-out is in fact a branch. You can commit to your local repository without touching anything anywhere else. Branches can be merged and forked very easily, and locally.

You can exchange code with other people on an individual level. Let's say that you and I are doing similar work, but we aren't ready to release it to the public. We both have a branch of the codebase. I can make my repository available to you (over http, incidentally) and let you merge my work into yours. And you can then do the same. So, you and I can have our own little worlds, which we easily merge into a new little world, separate from the bigger picture – but when we are ready, the maintainer of the bigger picture world can merge our little world back into the main codebase.

I'm starting to think that DVCSs are better in any case (local commits are very, very nice), but they're especially valuable when you have projects spread out over many people with everyone doing their own thing. If there is one single direction of development, it's not as important, but judging from what has been said here there will be many concurrent things going on.

Interesting! I suspect the general way we use it will be about the same, but being able to merge branches into each other without going through the main trunk is a neat idea.

In the last place I worked, we used CVS, and everyone had commit privs to everything and just remembered who "owned" what bits. I've also seen things organized as a central main branch which only a few people had write privs to, and everyone got their own branches that the senior devs would merge in when/if they decided it was ready for release.

I suspect the MUD code is a bit more tightly coupled than I"d like for the "everyone commits" model… conflict resolution is always ugly, no matter how good the vcs is.

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.

That's what most people think until they start playing around with it. It makes it very easy to fork and then merge again, unlike SVN and especially CVS, where forking is easy but the merging part is harder. When you have decentralized repositories, it's a lot easier to have people working on a side project that later gets reintegrated into the main code.

Many open source projects use DVCS to great success. The Linux kernel is an example of a "small" program that uses git. Ubuntu uses bzr all over the place (e.g. launchpad). Don't know any specific mercurial projects off the top of my head, but that's my fault for ignorance since I know there are several out there.

I was looking over the docs for mercurial and it uses http on port 80. Does this mean that, since my ISP blocks incoming connections on that port, nobody would be able to access my local repository? Or does it mean that anyone wishing to access my repository will have to remember an oddball portnum and then remember to use it?

This could be all academic now anyway, since thanks to Davion, we now have svn up and running. I just need to find out from him how to check stuff in :P

You can change the port, IIRC. bzr at least lets you export on a normal web-visible filesystem, and doesn't run its own server – or, it can run its own mini webserver that makes just the repos visible. Mercurial probably works similarly.

Actually, I have the same problem with my ISP blocking incoming port 80. So, we've set things up so that my domain points to the family server, which redirects to the right IP but on a different port. Kind of annoying, but, well…