Comparison of Constant....

Posted by Alyce on Thu 08 Sep 2016 02:37 AM — 10 posts, 35,461 views.

Alyce Thu 08 Sep 2016 02:37 AM #0

This has been bugging me... It's not TOO big an issue I don't believe, but it's one that is causing the compile to not be nice using smaugfuss 1.9 and compiling with cygwin.


comm.c: In function ‘void nanny_get_name(DESCRIPTOR_DATA*, char*)’:
comm.c:1886:44: warning: comparison of constant ‘255’ with boolean expression is always false [-Wbool-compare]
    if( check_playing( d, argument, FALSE ) == BERR )
                                            ^
comm.c:1954:12: warning: comparison of constant ‘255’ with boolean expression is always false [-Wbool-compare]
    if( chk == BERR )
            ^
comm.c: In function ‘void nanny_get_old_password(DESCRIPTOR_DATA*, char*)’:
comm.c:2049:12: warning: comp

I did some research a while back and someone had posted how to change the code to remove those warnings.. and it did.. however when connecting to a link-dead player, it caused segmentation faults, so I just changed it back and haven't really bothered with it since...

Now i'm just about done adding what I wanted to to the code-base and changed it to suit my needs, but that one lingering issue is still bugging me.

Mud works fine with the warnings there.. no segfault on connecting to link-dead... I just want them gone.

has anyone else ran across this issue? if so, how did you resolve it?

Fiendish USA Global Moderator Thu 08 Sep 2016 06:05 PM #1

So...

The C language didn't have a native bool type until C99. Before that, people would resort to stupid tricks like you can find in src/mud.h where it says

typedef unsigned char bool;
#define true 1
#define false 0

That means that the check_playing function in src/comms.c was created by a dickhead, because it declares that it semantically returns a boolean type but then actually returns three different unsigned chars (0, 1, 255). EXCEPT THAT IT ONLY DOES THIS IF __cplusplus IS NOT #DEFINED, but you wouldn't know that unless you went digging somewhere else (back in src/mud.h)! If _cplusplus *is* defined, then you have a function that actually returns a bool, and each of those "return BERR;"s is actually just returning true because anything not zero is true in C++. And then of course the compiler is then trying to convert those real booleans back into integers so that they can be compared against 255, except that true converts to 1 and false converts to 0, neither of which will equal 255. Sigh.

Getting that warning means that you're using a C++ mode compiler. You might try switching to a C compiler instead.

If I were going to fix this for real, I'd make check_playing declare that it returns unsigned char (or int) so that it stops converting into booleans instead of doing these only-sometimes-fake "bool" shenanigans.

Alyce Fri 09 Sep 2016 03:25 AM #2

well im compiling in cygwin for the moment. My bandwidth is severely limited right now so it's not possible to add any packages or change any. When I put it on an actual server with the proper libraries and stuff, I am assuming this will go away correct?

Nick Gammon Australia Forum Administrator Fri 09 Sep 2016 09:07 PM #3

No, I doubt it. How are you compiling? If you are using g++ you are compiling in C++ mode. If gcc then it is C mode. Also the suffix of your source file might affect it.

Alyce Sat 10 Sep 2016 01:15 AM #4


gcc-core                                5.4.0-1                          OK
gcc-g++                                 5.4.0-1                          OK

Kasji Sat 10 Sep 2016 05:25 AM #5

So, BERR is defined as the number 255.

check_playing() returns a bool.

In C, in Smaug, bool is type defined as an int or maybe short int. So check_playing() == BERR in C would be comparing 2 numbers.
[EDIT] Er, unsigned char like Fiendish said.

You're using C++ though, and as such, you're comparing a true/false from check_playing() to a number.

The change I made on my code was to change check_playing() from a bool return value to an int return value.

int check_playing(Blah blah blah)
{
Stuff
}

Alyce Sat 10 Sep 2016 05:38 AM #6

That is what I did at first to get rid of the warnings, and it worked to that extent.. however in doing so, when connecting to a link-dead player, or when logging on when connected it triggered segmentation faults.

It works just fine with the warnings there, it's just an eye sore when compiling.

Kasji Sat 10 Sep 2016 06:11 AM #7

I'm not running Smaug, so I can't say for sure how different our codes are, but... Recall that as a bool, check_playing will always evaluate as false. It's possible that something inside the if statement block is causing the crash, but it never happens while check_playing returns a bool because that block never gets executed (due to the if statement always evaluating as false).

Alyce Sat 10 Sep 2016 06:34 AM #8

I will be able to do more in depth looking with GDB but with my limited bandwidth I can't get it downloaded to my cygwin packages... I'll have to wait for a proper server

Kasji Sun 11 Sep 2016 10:38 PM #9

A trick that I use a lot when I don't have gdb available (for a while my mud wasn't dumping cores), is bug messages. I place bug messages around the area of code where the crash is happening, and can use that to narrow down the line that is causing the crash since I know the crash has to be happening before a bug message if it doesn't print out, or after a particular bug message if it does print out.