Advice on removing valid (but minor) compiler warnings

Basically I'm a novice in C programming and I'm working on a program that produces a lot of compiler warnings. I don't want to just turn off the warnings, I'd really like to make good (or acceptable ;-) code changes to correct the individual occurrences. That way when I get more warnings I'll actually notice them instead of them being lost in the crowd.

So take this example:

Code:

---

m_ptr->confused += 10 + randint0(p_ptr->lev) / 5;

---

confused is a byte.

10 + randint0(p_ptr->lev) / 5 can't be greater than 20 (in fact it can't be greater than 19.8, I believe). However if the same effect is applied repeatedly eventually 'confused' could overflow. So to be completely safe should I have something like ...

Code:

---

m_ptr->confused += (m_ptr->confused>236)?10 + (byte)randint0(p_ptr->lev) / 5 : 0;

---

?

It seems to me you are trying to deal with an imaginary problem that almost certainly has nothing to do with any of the compiler warnings you want to clean up.

But I could be wrong. Why don't you post the warnings?

Quote:

---

Originally Posted by MK27

But I could be wrong. Why don't you post the warnings?

---

Well this one is "warning C4244: '+=' : conversion from 's32b' to 'byte', possible loss of data" Hence the (byte). 96 of the 207 warnings are from type conversion.

But if you add a cast the warning goes away?

Code:

---

m_ptr->confused += 10 + (unsigned char)randint0(p_ptr->lev) / 5;

---

I notice you used (byte) in your alt version, which should work too I guess.

That's certainly very common; there are tons of standard functions that want a "const char*" and you can use a cast to eliminate those warnings if your parameter is really just a "char*".

But as for checking the value with your ternary operation, that will not matter to the compiler* one way or the other. It may be a good idea anyway, of course. But if you know the execution is such that data loss (or wrap-around) will actually be impossible, then it's totally unnecessary; technically plain old arithmetic could be used to wrap around int values too, but generally you don't need to check for that possibility.

* if you think about it you should be able to intuit why it CANNOT matter to the compiler, which is to say it can't issue a warning because you did or did not add an error checking routine. Although the warning may prompt you to write one, that will not change the warning...

Quote:

---

Originally Posted by MK27

But if you add a cast the warning goes away?

---

Yes.

Quote:

---

But as for checking the value with your ternary operation, that will not matter to the compiler* one way or the other.

---

I didn't think it would. But having had my attention drawn to this line of code that (I believe) theoretically could overflow aren't I better off doing something about it?

If the code would actually 'peg' at 256 instead of wrapping round then that's a different matter, but C doesn't do that, does it?

Quote:

---

Originally Posted by PaulBlay

But having had my attention drawn to this line of code that (I believe) theoretically could overflow aren't I better off doing something about it?

---

I don't *think* you can cause an overflow with arithmetic, the values just wrap around.

If you aren't sure that an error can't happen, then you definitely need to account for that in your programming. Probably getting scolded about type mismatches is enough to create a (pavlovian*)response eventually, and maybe just adding the cast will get you to think about the implications, so it's all good. I use gcc -Wall and I have never seen a compiler warning that could not be dealt with; they are not irrational and thank the gods for them.

As long as you understand that it's adding the cast, and not the error check, that cues it.

The compiler is merely trying to warn you that the int used in the calculation can become truncated when converted into a byte (since a byte can't hold the entire range of an int).
So to avoid these warnings, first and foremost, try to use the same types or use code that causes integer promotion (ie smaller to bigger). If using a function that returns something like that, use a cast to silence the warning, but make sure it actually doesn't truncate that returned number.

Quote:

---

there are tons of standard functions that want a "const char*" and you can use a cast to eliminate those warnings if your parameter is really just a "char*".

---

You do not need a cast in this case. You only need to cast when you have a const char*, and you need to pass it into a function which takes a char*. Of course in this case, the cast probably just covers up a problem in your code.

Quote:

---

Originally Posted by bithub

You do not need a cast in this case.

---

Of course you don't need one, but (gcc) will still always warn you. Because I submit code to other people who expect it to compile flawlessly (which is fair, if you are a packager it's not really your job to decide if a compiler warning in several thousand lines of code is relevant), I would include a cast to eliminate the warning.

Quote:

---

Of course you don't need one, but (gcc) will still always warn you

---

No it wont.

Tell me what gcc compile command will generate a warning with this code:

Code:

---

#include <stdio.h>

void foo(const char* const_text)
{
    printf("No compiler warnings: %s\n", const_text);
}

int main(void)
{
    char text[] = "this is some text";
    foo(text);
    return 0;
}

---

Point taken! To be honest, I think most of the functions I'm thinking of are from gtk. I just went thru some code looking for "(const" and the cast is actually (const gchar*) on a gchar* -- so maybe these warnings are only for non-standard types (which would corroborate with the OP) ?

Quote:

---

Originally Posted by MK27

Point taken! To be honest, I think most of the functions I'm thinking of are from gtk. I just went thru some code looking for "(const" and the cast is actually (const gchar*) on a gchar* -- so maybe these warnings are only for non-standard types (which would corroborate with the OP) ?

---

Passing a non-const to a const function should be fine. The other way around is always WRONG (but may be cast to remove the warning, and if you also know the function doesn't ACTUALLY change the content, is permissible - but why is the interface not const in the first place if that is the case). I doubt the type has anything to do with it.

--
Mats

Just to make sure I wasn't lying to myself and others I went back to check and you're right, it wasn't passing in, it was assigning the pointer (which I actually changed those to real consts, since they are not to be changed for a reason). The (const gchar*)'s are frivolous, I guess. :(