quixadhal
Wizard
Group: Members
Posts: 1,256
Joined: Oct 17, 2007
|
#61 Posted Oct 5, 2008, 5:13 pm
|
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.
|
......................... 
Last edited Oct 5, 2008, 5:15 pm by quixadhal
|
|
Caius
Conjurer
Group: Members
Posts: 114
Joined: Oct 21, 2006
|
#62 Posted Oct 5, 2008, 5:38 pm
|
quixadhal said: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.
Compilers not implementing C++98 is probably not worth wasting breath on.
|
......................... SWR2 Refactor - The improved SWR 2.0 codebase.
|
|
MacGregor
Magician
Group: Members
Posts: 54
Joined: Oct 3, 2008
|
#63 Posted Oct 5, 2008, 5:57 pm
|
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 
And no, 3.4.6 didn't have any problems with your warning flags.
|
|
|
Davion
Idle Hand
Group: Administrators
Posts: 1,188
Joined: May 14, 2006
|
#64 Posted Oct 5, 2008, 7:03 pm
|
We're starting up the round-table discussion on the server in a few minutes, if anyones interested in joining the project.
|
......................... 
|
|
David Haley
Wizard
Group: Members
Posts: 5,730
Joined: Jun 30, 2007
|
#65 Posted Oct 5, 2008, 11:10 pm
|
Quote: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.
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.
|
|
|
MacGregor
Magician
Group: Members
Posts: 54
Joined: Oct 3, 2008
|
#66 Posted Oct 6, 2008, 2:24 am
|
Okay, messing around with compiling this with g++ 3.4.6, I get these warnigns as I posted earlier:
Code (text): 1
2
3
4
5
6
7
8
9
10 | # 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:
Code (text): 1
2
3 | 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?
|
|
|
Samson
Evil Overlord
Group: Members
Posts: 2,631
Joined: May 13, 2006
|
#67 Posted Oct 6, 2008, 2:30 am
|
MacGregor said:The offending line is this:
Code (text): 1
2
3 | 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.
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,256
Joined: Oct 17, 2007
|
#68 Posted Oct 6, 2008, 2:50 am
|
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.... :(
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34 | 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:
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 | 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!
|
.........................
|
|
MacGregor
Magician
Group: Members
Posts: 54
Joined: Oct 3, 2008
|
#69 Posted Oct 6, 2008, 5:18 pm
|
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.
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,256
Joined: Oct 17, 2007
|
#70 Posted Oct 6, 2008, 5:50 pm
|
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.
|
.........................
|
|
MacGregor
Magician
Group: Members
Posts: 54
Joined: Oct 3, 2008
|
#71 Posted Oct 6, 2008, 6:08 pm
|
Here's what I already stuck near the top of merc.h:
Code (text): 1
2
3
4
5
6
7
8
9
10 |
/*
* 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  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.
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,256
Joined: Oct 17, 2007
|
#72 Posted Oct 6, 2008, 10:49 pm
|
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. 
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. :)
|
.........................
|
|
|
|
MacGregor
Magician
Group: Members
Posts: 54
Joined: Oct 3, 2008
|
#74 Posted Oct 7, 2008, 12:19 am
|
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.
|
|
|
David Haley
Wizard
Group: Members
Posts: 5,730
Joined: Jun 30, 2007
|
#75 Posted Oct 7, 2008, 7:26 am
|
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.
|
|
|
