18 Jan, 2010, OnwardToFutility wrote in the 1st comment:
Votes: 0
Hello,

I wanted to take a stab at playing around with NakedMud, and followed these instructions: http://www.nakedmud.org/trac/wiki/Cygwin...

On compiling, I'm getting an absolute ton of warnings. The mud still compiles and runs fine anyways, but I'm a little nervous about leaving warnings alone, so was hoping someone could point me in the right direction as to why they are popping up.

The first is this… it shows up a load, in all but a few of the files:

utils.c: In function `name_as_uid':
utils.c:442: warning: array subscript has type `char'


for(; name[i] != '\0'; i++)
@@ if(!isdigit(name[i]))
return NOBODY;


Then there is this one:

command.c: In function `cmdTryChecks':
command.c:269: warning: dereferencing type-punned pointer will break strict-aliasing rules


if(retval == NULL)
log_pyerr("Error running Python command check, %s:", cmd->name);
@@ else if(retval == Py_False)
cmd_ok = FALSE;


Any enlightenment out there? Perhaps a newb such as myself should start with a different codebase? :D
18 Jan, 2010, David Haley wrote in the 2nd comment:
Votes: 0
utils.c:442: warning: array subscript has type `char'

This probably means that your array index has type 'char' – that is, that 'i' is typed to char. I'm not really sure why it's warning about that, but to fix it change i to int or something.

I don't really know what the other warning is about. Py_False might be #define'd to something weird.

What version of gcc do you have?
19 Jan, 2010, OnwardToFutility wrote in the 3rd comment:
Votes: 0
David Haley said:
utils.c:442: warning: array subscript has type `char'

This probably means that your array index has type 'char' – that is, that 'i' is typed to char. I'm not really sure why it's warning about that, but to fix it change i to int or something.

I don't really know what the other warning is about. Py_False might be #define'd to something weird.

What version of gcc do you have?


i is already int… here's the entirety of that particular function ( probably woulda been more helpful in the first place, huh? :P ):

// returns a name as a UID, or -1 if it does not translate
int name_as_uid(const char *name) {
if(name == NULL)
return NOBODY;
int i = 0, uid = NOBODY;
for(; name[i] != '\0'; i++)
if(!isdigit(name[i]))
return NOBODY;
sscanf(name, "%d", &uid);
return uid;
}


gcc:
Quote
$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure –verbose –program-suffix=-3 –prefix=/usr –exec-prefix=/usr –sysconfdir=/etc
–libdir=/usr/lib –libexecdir=/usr/lib –mandir=/usr/share/man –infodir=/usr/share/info –enable-languages=c,ada,c++,d,f77,pascal,java,objc –enable-nls
–without-includedgettext –enable-version-specific-runtime-libs –without-x –enable-libgcj –disable-java-awt –with-system-zlib –enable-interpreter
–disable-libgcj-debug –enable-threads=posix –enable-java-gc=boehm –disable-win32-registry –enable-sjlj-exceptions –enable-hash-synchronization
–enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
19 Jan, 2010, elanthis wrote in the 4th comment:
Votes: 0
It is easy to hit Google first and the forum second. :)

For the first issue, try changing the int to unsigned int. http://www.devolution.com/pipermail/sdl/...

For the second, it sounds like maybe it's just a compiler issue that upgrading would help (gcc 3.4 is seriously ancient), and if you can't, try -fno-strict-aliasing. http://www.linuxquestions.org/questions/...
19 Jan, 2010, Confuto wrote in the 5th comment:
Votes: 0
I strongly suggest updating GCC before attempting to fix any of the warnings you're seeing. I get very few warnings when compiling NM using GCC 4.3.3.

As for the 'dereferencing type-punned pointer' warning - I get that too. I blame Python.
19 Jan, 2010, David Haley wrote in the 6th comment:
Votes: 0
+1 to Elanthis and Confuto – try upgrading gcc first. I think that the Cygwin package list has a more recent version, so perhaps try that first.

I don't really understand what the first warning is about; it strikes me as odd for it to complain about a signed vs. unsigned type in an array index. And I don't know why it's talking about a char index because it's typed as something else…

Anyhow, upgrade the compiler, then see what warnings you get.
19 Jan, 2010, OnwardToFutility wrote in the 7th comment:
Votes: 0
Woops. I just picked gcc in the setup, not even realizing it wasn't the current version. Anyways, rectified now and at 4.3.4, but still getting the same warnings.

And also now this has joined in:

Quote
Compiling gameloop.c
In file included from mud.h:12,
from gameloop.c:10:
wrapsock.h:50: warning: `optarg' redeclared without dllimport attribute: previous dllimport ignored
wrapsock.h:51: warning: `optind' redeclared without dllimport attribute: previous dllimport ignored
wrapsock.h:52: warning: `optopt' redeclared without dllimport attribute: previous dllimport ignored
wrapsock.h:53: warning: `opterr' redeclared without dllimport attribute: previous dllimport ignored
wrapsock.h:54: warning: `optreset' redeclared without dllimport attribute: previous dllimport ignored
gameloop.c: In function `game_loop':
gameloop.c:406: warning: pointer targets in passing argument 3 of `accept' differ in signedness


Tons of those, in pretty much every file.

Since Confuto mentioned being able to compile basically warning free, I thought perhaps my Cygwin install got messed up somehow, so I killed it all and reinstalled fresh. Same warnings and such.

Could this in any way be something else about my computer? I know little about the Unix environment Cygwin is emulating here, so have no idea if something else could be causing this. Just seems bizarre that it seems this codebase is supposed to work flawlessly on Cygwin (as evidenced by Confuto), but is losing its mind for me. :P

Anyways, thanks for the help so far… there are TONS of those warnings that I don't particularly want to go in and change (since I just want to play with a while to check it out… I would if I was settled on this for a base), so I guess if this can't be explained I'll move on and try my luck with something else. :)
19 Jan, 2010, David Haley wrote in the 8th comment:
Votes: 0
Well, Confuto could be compiling on a different Unix environment. The warnings you got from wrapsock.h could be coming from some attempt to work around Windows-with-Cygwin or something like that.

When you say that you get "TONS" of warnings like these, how many are you talking about, roughly speaking?

It's relatively unlikely that this is due to some problem on your computer in general. I guess this might be a dumb question, but do you also have the most recent version of NakedMUD?

If you just want to mess around, you can probably leave the warnings as-is while you experiment. If you decide to stick with the codebase, that's when you'd think about cleaning stuff up.
19 Jan, 2010, Tyche wrote in the 9th comment:
Votes: 0
You can safely ignore the warnings.
19 Jan, 2010, elanthis wrote in the 10th comment:
Votes: 0
That may be so, but what are the proper fixes (header file reorganization) ? Those warnings may be superfluous, but they'll drown out other potentially useful warnings if you don't get rid of them.
19 Jan, 2010, Tyche wrote in the 11th comment:
Votes: 0
elanthis said:
That may be so, but what are the proper fixes (header file reorganization) ? Those warnings may be superfluous, but they'll drown out other potentially useful warnings if you don't get rid of them.


Passing a signed char to ctype.h functions is undefined behavior under C99, so…

You could rewrite all the calls to do either.
isalpha ((unsigned char) ch);
or
int c = (unsigned char) ch;
isalpha ©;

2) accept arg 3 error

Accept wants socklen_t* as the third parameter, not unsigned int*.

3) dllexport redefinition

Add the attribute to the redeclarations…
__declspec(dllimport)

Any others?
19 Jan, 2010, Tyche wrote in the 12th comment:
Votes: 0
Tyche said:
Add the attribute to the redeclarations…
__declspec(dllimport)


Sorry the better practice is to not declare them at all and comment them out, rather than redeclare them wrong as what's already declared in unistd.h is right.
19 Jan, 2010, Confuto wrote in the 13th comment:
Votes: 0
I should have made it clear that I am not using Cygwin. I'm sorry you went to all that trouble, I really should've clarified.

Extending NakedMUD is generally done through the use of modules (either C or Python). One can build an entire game without ever modifying any of the stock source code - this is, in fact, the recommended way of building a game as it preserves compatibility with future versions of the base. If it is true that the warnings can be safely ignored, I strongly suggest that you do so. Elanthis raises a good point, though if you never modify the stock source you should be able to identify warnings related to your own C modules fairly easily.

Perhaps it's bad of me to suggest that you ignore the warnings, but I honestly don't see the point in addressing them given that:
1. They appear to be related to your choice of platform.
2. They're apparently trivial.
3. Modifying the stock source will frustrate you in the future should you need to patch to a new version.
19 Jan, 2010, Tyche wrote in the 14th comment:
Votes: 0
Actually some of the code in handler.c is problematic regardless of platform.

To illustrate the problem:
#include <stdio.h>
typedef long bitvector_t;
typedef unsigned char bool;
#define IS_SET(flag,bit) ((flag) & (bit))
#define SET_BIT(var,bit) ((var) |= (bit))

#define FIND_SCOPE_VISIBLE (1 << 18)

int foo(bool must_see) {
if (must_see)
return 1;
return 0;
}

int main() {
bitvector_t bv = 0;
SET_BIT(bv,FIND_SCOPE_VISIBLE);
printf("%d\n",foo(IS_SET(bv,FIND_SCOPE_VISIBLE)));
return 0;
}


$ ./nakedproblem.exe
0

There's multiple LOC that attempt assigned the results of IS_SET to a bool in the same fashion I do above.

I'd submit all these problems to the author to be patched.
19 Jan, 2010, Tyche wrote in the 15th comment:
Votes: 0
Whoops.. I went to run a diff and discovered I checked out the wrong tree. It seems some of the issues I found were fixed.

Anyway here's a diff to patch it that fixes it on Cygwin to get rid of almost all the warnings.
Index: scripts/module.mk
===================================================================
— scripts/module.mk (revision 81)
+++ scripts/module.mk (working copy)
@@ -122,7 +122,7 @@
PYTHONTOP = /usr/include

# the folder where python headers are located
-C_FLAGS += -I$(PYTHONTOP)/python2.4
+C_FLAGS += -I$(PYTHONTOP)/python2.5 -Wno-char-subscripts

# libraries we have to include.
-LIBS += -Xlinker -export-dynamic -lm -ldl -lutil -L/usr/lib/python2.4/config -lpython2.4
+LIBS += -lm -ldl -lutil -L/usr/lib/python2.5/config -lpython2.5
Index: wrapsock.h
===================================================================
— wrapsock.h (revision 81)
+++ wrapsock.h (working copy)
@@ -45,14 +45,6 @@
/*#include <limits.h> normally included by socket*/
/*#include <sys/time.h> timeval normally included by types */

-/* Extern globals */
-/* Used by geopt to check the options supplied by the user */
-extern char *optarg; /* option argument */
-extern int optind; /* index of the next argument on return */
-extern int optopt; /* last known option on return */
-extern int opterr; /* error on return */
-extern int optreset; /* not used here */
-
/* Defines */
/* defined before the right type get a chance to be defined */
#ifndef socklen_t
Index: gameloop.c
===================================================================
— gameloop.c (revision 81)
+++ gameloop.c (working copy)
@@ -399,7 +399,7 @@
/* check for new connections */
if (FD_ISSET(control, &rFd)) {
struct sockaddr_in sock;
- unsigned int socksize;
+ socklen_t socksize;
int newConnection;

socksize = sizeof(sock);


Yes, the -Wno-char-subscripts above just removes some of the messages. ;-)
20 Jan, 2010, OnwardToFutility wrote in the 16th comment:
Votes: 0
Well that is much better. :)

I am an obvious noob here, but I really wanted to be able to learn on something I wouldn't have to rip 90% of the guts out of before starting to make what I wanted, so NakedMud seemed the obvious choice. But all those warnings were fairly discouraging… :P

So, thanks, Tyche. Compiles with only a couple warnings now, but that is more than manageable for me, and the changes are minor enough to make future updating from the official sources not overly problematic.

Thanks to everyone else as well… I was kinda expecting to get ridiculed some for this topic, but to my amazement it didn't happen. :)
20 Jan, 2010, elanthis wrote in the 17th comment:
Votes: 0
We don't make fun of people who have yet to learn something but are trying; even Tyche at one point in time didn't know anything about programming, back before he invented C and the Internet. ;) It's the people who don't know what they're doing and argue with anyone offering advice we ridicule. And people with yellow shirts.
0.0/17