Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Bing, Sogou, Yahoo!

Members: 0
Guests: 6
Stats
Files
Topics
Posts
Members
Newest Member
477
3,705
19,232
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » compile failure across all FU...
Forum Rules | Mark all | Recent Posts

compile failure across all FUSS bases
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Apr 8, 2008, 8:53 am
Go to the top of the page
Go to the bottom of the page

addis
Fledgling
GroupMembers
Posts6
JoinedApr 4, 2008

Hi,
This is my first post but ive been hunting around the forums for some time looking for a potential solution. Having problems compiling any of the FUSS sources but im particuarly trying to compile SWR FUSS. The only bases ive managed to compile so far have been circle and smaug1.4a (and smaug crashes upon login, it compiles with an error simmilar to the one im having with fuss).


Heres what happens when i try to compile swrfuss:
make -s swreality
Compiling o/act_comm.o....
act_comm.c: In function `send_rip_screen':
act_comm.c:1455: warning: comparison is always true due to limited range of data type
act_comm.c: In function `send_rip_title':
act_comm.c:1471: warning: comparison is always true due to limited range of data type
act_comm.c: In function `send_ansi_title':
act_comm.c:1487: warning: comparison is always true due to limited range of data type
act_comm.c: In function `send_ascii_title':
act_comm.c:1503: warning: comparison is always true due to limited range of data type
make[1]: *** [o/act_comm.o] Error 1
make: *** [all] Error 2

I get this same error compiling any fuss source (ive disabled imc in the makefile here but when enabled it pops up with the same errors)

These are all stock sources so im assuming theres something wrong with my setup. atm im running:

Ubuntu Gusty Gibbon on PPC (2.6.22-14-powerpc)
Tried using GCC4, GCC3.3 GCC4.1, GCC4.2 all with the same error
libc6 2.6.1-ubuntu10

Any idea as to what could be causing this? ive been working at it for a couple of days and im not getting too far :) any help would be appreciated.

Thanks for you time
Addis
       
Post is unread #2 Apr 8, 2008, 9:37 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Could you post the lines in question along with the declaration types of any variables involved?

Chances are that something signed is being compared against something unsigned. The warning is telling you that the comparison is meaningless due to the relative possible ranges of the things being compared.

It's probably not something wrong with your setup; chances are that the code just hasn't been compiled on your platform/compiler-version combination and so the maintainers haven't encountered this particular problem to fix yet. The SWR packages tend to be a bit less heavily pounded than the straight SMAUG packages. :smile:
       
Post is unread #3 Apr 8, 2008, 9:53 am
Go to the top of the page
Go to the bottom of the page

addis
Fledgling
GroupMembers
Posts6
JoinedApr 4, 2008

ok sure, heres the error from act_comm.c

void send_rip_screen( CHAR_DATA * ch )
{
FILE *rpfile;
int num = 0;
char BUFF[MAX_STRING_LENGTH * 2];

if( ( rpfile = fopen( RIPSCREEN_FILE, "r" ) ) != NULL )
{
while( ( BUFF[num] = fgetc( rpfile ) ) != EOF )

here the while command is line 1455, the comparison thats coming up with the error

The other three errors are pretty much identical pieces of code, if theres a general problem here i cant spot it, but then again this is my first time playing with a MUD codebase, just taking a look as a programming exercise atm :).

Biggest concern atm is the whole running on PPC thing :)

Thanks for your help and the quick response!
Addis
       
Post is unread #4 Apr 8, 2008, 11:24 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I guess that EOF is defined as 256 on your system, and therefore, no char will ever be equal to 256 (because chars are limited to 0.255, or half that when signed). I thought that EOF was defined as -1, but this is probably a platform issue.

What you could do is something like this. Change:
while( ( BUFF[num] = fgetc( rpfile ) ) != EOF )
{
    /* body */
}


To:
int c;
while( ( c = fgetc( rpfile ) ) != EOF )
{
    BUFF[num] = (char) c;
    /* body */
}


What I have done here is to introduce an intermediate int to capture the full range of values, and then once we've determined that it's not EOF -- i.e. it is an actual character -- we assign it into our buffer of characters.
       
Post is unread #5 Apr 8, 2008, 1:07 pm
Go to the top of the page
Go to the bottom of the page

addis
Fledgling
GroupMembers
Posts6
JoinedApr 4, 2008

Thanks for that, it worked brilliantly and set me on the right track for the rest of it :)

There were a stack more errors of the same kind as this after the ones you managed to fix, all arising because aparrently PPC assumes all chars are unsigned by default (rather than x86 which assumes there all signed). So all i did was add "-fsigned-char" as an option to gcc in the makefile to change that to assume all chars are signed. This seemed to fix the problems :)

Im all up and running now so thanks alot for the help :)

maybe add this in as a commented option in the makefile for PPC users? (not that there are many :P)
       
Post is unread #6 Apr 8, 2008, 1:11 pm   Last edited Apr 8, 2008, 1:12 pm by David Haley
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Glad it helped. :wink: I agree, adding it to the sources would probably be a good idea. :smile: I compiled SmaugFUSS for PPC a while ago and had to work through a fair number of warnings/errors, but for some reason this wasn't one of them.

That said, the int trick above should work on all platforms, so it might also work to just change the source for everybody (not just PPC) to look like that. But the -fsigned-char would have to be a PPC-specific thing (probably).
       
Post is unread #7 Apr 8, 2008, 3:24 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Just as a cautionary note. If a platform uses unsigned char's by default and you cast them to signed char's, it might introduce some sorting problems if any extended character sets are in use. I know some systems define EOF as an int, rather than a char, so they can still return 0..255 and -1 (255 maps to -1 when you go from unsigned char to signed char).

Of course, if you're in such an environment, Smaug (and all Diku) code probably has a few other nasty surprises waiting for you too.
       
Post is unread #8 Apr 8, 2008, 3:37 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Just as an off topic slant, but does anyone actually use that send_rip_screen stuf? Do any current mud clients or terminal programs even support RIP? Am I the only one here old enough to even remember what it was? :P
       
Post is unread #9 Apr 8, 2008, 4:46 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Samson: I don't use it, nor do the clients I run use it...

Quixadhal: I agree that it could cause all kinds of nasty surprises. Frankly though I think it is very bad form for a platform to default "char" to being unsigned: that is what the unsigned keyword is for! Grumble grumble. Well, anyhow...
       
Post is unread #10 Apr 8, 2008, 9:42 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Samson said:

Just as an off topic slant, but does anyone actually use that send_rip_screen stuf? Do any current mud clients or terminal programs even support RIP? Am I the only one here old enough to even remember what it was? :P


I've still got it in my mud's code, but I don't know of any clients other than ripterm (which I'd hardly call 'current') that use it.. that being said, nope, you're not the only one here that old... not even taking into account your birthday the other day, in fact, you're still younger than me. :tongue:
       
Post is unread #11 Apr 9, 2008, 3:48 am
Go to the top of the page
Go to the bottom of the page

addis
Fledgling
GroupMembers
Posts6
JoinedApr 4, 2008


DavidHaley said:

Frankly though I think it is very bad form for a platform to default "char" to being unsigned: that is what the unsigned keyword is for! Grumble grumble. Well, anyhow...


It seems to be taken as a more efficient standard for PPC :) and yeah, im probably gonna have a few more problems with it, but now it compiles ok I can have a play, havent run into anything tricky so far.
       
Post is unread #12 Apr 28, 2008, 7:08 am
Go to the top of the page
Go to the bottom of the page

Krylan
Fledgling
GroupMembers
Posts39
JoinedApr 14, 2005

So, I'm getting similar errors on Ubuntu Hardy Heron, on a 64 bit version. Though, its an SWR FUSS.

act_wiz.c: In function ‘do_invis’:
act_wiz.c:3535: warning: the address of ‘arg’ will always evaluate as ‘true’
act_wiz.c: In function ‘do_bestow’:
act_wiz.c:4197: warning: the address of ‘arg’ will always evaluate as ‘true’
act_wiz.c:4217: warning: the address of ‘cmd_tmp’ will always evaluate as ‘true’
act_wiz.c: In function ‘do_setrace’:
act_wiz.c:6826: warning: the address of ‘arg1’ will always evaluate as ‘true


3535 is:
   if( arg && arg[0] != '\0' )
       
Post is unread #13 Apr 28, 2008, 9:13 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

This is because arrays declared on the stack always have non-zero values, so the check if (arg) is useless. It suffices to check if ( arg[0] != '\0' ) in this case.
       
Post is unread #14 Apr 28, 2008, 10:47 am
Go to the top of the page
Go to the bottom of the page

Krylan
Fledgling
GroupMembers
Posts39
JoinedApr 14, 2005

Ah, makes sense. Thats what I thought I should do, but I wanted to double check.
       
Post is unread #15 Apr 28, 2008, 2:35 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

People often grumble about my code, as every function has every single variable pre-assigned with a value on entry... and every array gets a call to bzero()... and I use calloc() instead of malloc(). Yet it makes the rest of the code much simpler, since I can then rely on checks for 0.

One thing the perl language has that I always wished C had, is the 0E0 constant. That's a 0 numeric value with a "true" evaluation... so if you pass in a 0 for a value as 0E0, it passes the (yes, you gave me something) checks.
       
Post is unread #16 Apr 28, 2008, 2:42 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Yes, I also like languages that distinguish between the lack of value (i.e. nil) and the actual false/empty value. Actually this isn't a huge problem in C, typically, except when you're dealing with strings, and only then because strings are pointers and bad things happen when you do things to null pointers. If strings were actual objects like in C++ then life is easier for a few reasons.
       
Pages:<< prev 1 next >>