25 Dec, 2008, Venrexx wrote in the 1st comment:
Votes: 0
I need help with a few parts of code, I am trying to clean up all the warnings in my compile but I have hit a few snags. The warnings and code it applies to are below.

save.c:833: warning: comparisons like X<=Y<=Z do not have their mathematical meaning
if ( QUICKMATCH( obj->name, obj->pIndexData->name ) == 0 )

second code and error is
ident.c:312: warning: pointer targets in passing argument 3 of 'getsockname' differ in signedness
if (getsockname(d->descriptor, (struct sockaddr *)&us, &ulen) < 0)

I have no idea if this is enough information for you, I will add anything else you need.
Thanks you for any help.
25 Dec, 2008, Guest wrote in the 2nd comment:
Votes: 0
Moved to Smaug forum as this is probably more Smaug specific.

First off. What version of Smaug are you using? Both of those bugs have already been long ago fixed in SmaugFUSS, I think as far back as 1.6 if I'm not mistaken.

Your first problem is from how the QUICKMATCH macro is built.
#define QUICKMATCH(p1, p2)	(int) (p1) == (int) (p2)

It's comparing p1 to see if it's the same as p2. I'm not sure what the wording of the warning itself is supposed to mean, but in SmaugFUSS the macros were removed in favor of the more traditional str_cmp() methods in Smaug.

Your second one is more straightforward. The ulen parameter is not the same variable type the getsockname is looking for. I'd have to check how that was fixed in descriptor.c, but in SmaugFUSS the ident code in indent.c was removed very early on because it's mostly broken.
25 Dec, 2008, Venrexx wrote in the 3rd comment:
Votes: 0
Sorry for sounding nOObish, you lost me after quickmatch… I am still learning alot of code and the problems I face are that I am mainly a visual learner… I am using a DBS Smaug database, fixing compile issues, and the only files I have left to fix are in comm.c, grub.c, ident.c and save.c. There are several save.c: # :warning: comparisons like X<=Y<=Z do not have their mathematical meaning, they all have 0's on the end and if I could figure out how to resolve them all it would be great.. I have been working at this far too long today, I just want to finish lol
Also I cannot find that Define string anywhere.
26 Dec, 2008, Davion wrote in the 4th comment:
Votes: 0
Macro's are literally translated at compile time. So this->

if ( QUICKMATCH( obj->name, obj->pIndexData->name ) == 0 )

Translates to
if( (int) obj->name == (int)obj->pIndexData->name == 0 )

Not entirely too sure what you want done here, but it looks like you want to see if the two variables share the same address. So, if you want to check if they -do- share the same address, simply remove the == 0. If you want to see if they aren't the same address simply add a ! before QUICKMATCH.

The second one is probably ulen being defined as an int. Change the variable definition to size_t instead.
Probably like this now:
int ulen;

And you want it
size_t ulen;
26 Dec, 2008, quixadhal wrote in the 5th comment:
Votes: 0
Yes, and the wording of the warning is because the system call expects an unsigned integer (hence ulen, instead of len), whereas you're passing a signed integer. So, while they are the same number of bits, the logical comparison of anything negative vs. anything with the high-bit set doesn't work as you'd expect.

size_t is an unsigned integer where the length of the integer matches the system's pointer size (IE: 4 bytes for 32-bit CPU's, 8 bytes for 64-bit ones).
26 Dec, 2008, Venrexx wrote in the 6th comment:
Votes: 0
Thank you all so much, that size_t not only fixed the issue I was having with this file but it also fixed another issue in another file :grinning: Also I removed the ==0 and that worked just fine too!! You guys are really good at this stuff, I know I will be able to learn alot from the people here. :wink:
26 Dec, 2008, Guest wrote in the 7th comment:
Votes: 0
Also, in case the compiler ever whines about size_t, you can also use socklen_t for things like accept() and getsockname()
26 Dec, 2008, Sharmair wrote in the 8th comment:
Votes: 0
Venrexx said:
… :grinning: Also I removed the ==0 and that worked just fine too!! You guys are really good at this stuff, I know I will be able to learn alot from the people here. :wink:

If you just removed the ==0 part of the lines, you introduced bugs in your code. The
proper ways to fix the problem would be to fix the QUICKMATCH macro from:
#define QUICKMATCH(p1, p2) (int) (p1) == (int) (p2)

#define QUICKMATCH(p1, p2) ((int) (p1) == (int) (p2))

then, when you remove the ==0 you use !QUICKMATCH (note the !).
26 Dec, 2008, Venrexx wrote in the 9th comment:
Votes: 0
OK I followed what you said, I updated mud.h with the line #define QUICKMATCH(p1, p2) ((int) (p1) == (int) (p2)) and then updated all 8 entries in save.c with !QUICKMATCH. I still have no compile warnings or errors so looks like it worked either way lol. Thanks for the bit of advice :D
27 Dec, 2008, quixadhal wrote in the 10th comment:
Votes: 0
The thing here is that you need to understand what you're changing, not just change it and hope it works right.

If the original calls compared the results of the macro QUICKMATCH() against 0, and you remove the explicit comparison (== 0), you have reversed the logic of the statements. Namely, the C language treats any non-zero value as "true" and any zero-value as "false". So, if(QUICKMATCH()) is the same thing as if(QUICKMATCH() != 0). if(!QUICKMATCH()) negates that comparison.

If it "worked" either way, your code is either not doing anything at all, or the cases where the comparison would happen is not happening in your testing. The fact that it compiles does not mean it works, any more than putting random english words from a dictionary on a line makes a valid sentence.

Sorry if I'm sounding like I'm preaching here, but I'd rather people understand what they're actually doing, rather than just trial-and-error until it appears to work. It'll save you lots of headaches down the road. :)
27 Dec, 2008, Venrexx wrote in the 11th comment:
Votes: 0
So very true, hey if preaching gets the job done then I will be more than happy to learn from your preaching lol
27 Dec, 2008, David Haley wrote in the 12th comment:
Votes: 0
"Preaching" is generally the best solution in the long term, and listening to preaching and learning yourself is the best way to ensure that you will get even more "preaching" and help. :smile: Generally speaking, the worst thing to do is to give the impression that you just want a problem solved without understanding what's going on.
27 Dec, 2008, Venrexx wrote in the 13th comment:
Votes: 0
I want both, I want the problem solved and then I want explanations as to why it was done and why it applies to that situation. It is the way I learn the best. Doing it this way tells me how to do it in the future.
27 Dec, 2008, David Haley wrote in the 14th comment:
Votes: 0
Fair enough. The hope behind the lesson-style approach though is to give you the tools to solve the problems yourself. In the end, you will be able to do much greater things that way. The best thing you can do in return is try to ask precisely which things you don't understand about the concepts. That will help people give you better answers and make the process quicker.
27 Dec, 2008, Venrexx wrote in the 15th comment:
Votes: 0
That's the thing with me, If I cannot understand it, I more than likely cannot explain it. But in the future I will try.
27 Dec, 2008, David Haley wrote in the 16th comment:
Votes: 0
I'm not expecting you to explain the solution, or even the problem; I'm hoping that you can at least explain what it is that you don't understand about what people are telling you. If you truly understand absolutely nothing of what is being said, that's also important for us to know so that we can adjust our explanations. If we don't know where you stand, we can't effectively help you.
28 Dec, 2008, Venrexx wrote in the 17th comment:
Votes: 0
Understood, Basically the only way I can explain things though is the way that I have been, the reason I don't add more is because I generally do not understand any more about it and therefore cannot explain anything more other than "I need to fix this"