On 08/02/13 22:50, Robert Henig wrote: > I agree with this for sure. I'm dealing with inherited code and pulling hair > on several fronts. > > Turns out += is flawed as well but not because the low byte was not zero. > Casting as you suggest to (unsigned char) seems to take care of the promotion > problem. > > Thanks again everyone. > Bob. > > On Feb 8, 2013, at 1:17 PM, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > >> If you're just shuffling 8-bit wide chunks of data around, always, >> always, always use unsigned char. Or better yet, uint8_t. >
There are a few things you should do to deal with the problem. First, understand that you should /never/ use "char" in any code, except perhaps when you are actually storing strings and character data (and even then, only if you are sure you are limited to 7-bit ASCII). Of preference you should use "uint8_t" or "int8_t" from <stdint.h> - doing arithmetic with a type called "character" does not make logical sense. At the very least, use "signed char" and "unsigned char" explicitly, because you cannot assume the signedness of a plain "char" in any given C compiler. Explicit signedness is far better than relying on unreliable assumptions. Second, deal roughly with the original author until he too understands that plain "char" might be signed or unsigned. Thirdly, prefer to fix the original definitions to "uint8_t" rather than use a cast later, if that is possible in the code - aim to replace /all/ uses of "char" with "uint8_t" or "int8_t" as appropriate. Fourthly, compile your code with the "-funsigned-char" switch. Then plain "char" will be treated as unsigned by the compiler. That will make the original assumption correct, and give you a workaround for any remaining plain "chars" that you missed or could not easily fix. Hope that helps, David ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
