Hot!implicit type conversions with unsigned chars

Author
GraemeCAUK
New Member
  • Total Posts : 15
  • Reward points : 0
  • Joined: 2012/07/05 04:55:02
  • Location: 0
  • Status: offline
2018/03/14 05:38:38 (permalink)
0

implicit type conversions with unsigned chars

Hi all,
 
I'm writing a program which requires the use of unsigned chars. However, I'm constantly getting "implicit signed to unsigned conversion" warnings whenever I use an arithmetic or bitwise operator on one.
 
The result is that to get the following to build without a warning, for example:
 
    unsigned char test(unsigned char test_1, unsigned char test_2) {
        return (test_1 + test_2);
    }
 
I have to cast as follows:
 
    unsigned char test(unsigned char test_1, unsigned char test_2) {
        return ((unsigned char)(test_1 + test_2));
    }
 
This can't be necessary, can it?   The only thing I can think is that I've got my project or XC8 set up with some extremely draconian syntax settings.
 
Any advice would be greatly appreciated as the constant need to cast is both concerning and leads to some very unwieldy source code.
 
Graeme.
 
 
#1

12 Replies Related Threads

    mbrowning
    Just a Member
    • Total Posts : 910
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: implicit type conversions with unsigned chars 2018/03/14 05:56:22 (permalink)
    +1 (1)
    You can reduce the warning level. Recent versions of XC8 upped the default warning level. Agreed that it is annoying, but standard C integer promotions are the cause.
     
    You can make it a little less unpleasant by #include <stdint.h> - then you can use the standard type shortcuts like "uint8_t" which is a little less intrusive than "unsigned char".

    Can't remember. I've slept since then - Mark
    #2
    du00000001
    Just Some Member
    • Total Posts : 1784
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 07:40:25 (permalink)
    +1 (1)
    Welcome to the club of "C dummies" (just teasing).
     
    Most arithmetic operations in C have an integer result (implicitly defined). THUS . . .
    And the use of stdint.h serves little to mitigate this effect. But it makes the code more readable as the size of the variables is easier to discern.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #3
    GraemeCAUK
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Joined: 2012/07/05 04:55:02
    • Location: 0
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 08:02:41 (permalink)
    0
    Yes, I know about the default type of int in 'C'. It's more the plethora of warnings that was bothering me. I've just moved over to XC8 from MikroC, with which I used 8 bit data all the time without any kind of implicit conversion warning. I'm reluctant to reduce the warning level though because I could miss some potential howlers, so I'll definitely start using uint8_t to keep things tidy.
    #4
    du00000001
    Just Some Member
    • Total Posts : 1784
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 08:07:42 (permalink)
    +1 (1)
    It's only recently that XC8 & Co. matured significantly - including a multitude of type conflict warnings.
    Although this requires a lot of explicit type casting to get rid of most (not all) of the warnings, I consider type casts as some sign of maturity of the programmer: showing s/he is aware of the conflicts.
     
    The unfamous ANSI standard still allows for a variety of implementations regarding the warnings. And not every compiler producer even strives for the ANSI labeling.
    (Plus: some old dogs like me still love the pre-ANSI K&R "standard".)

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #5
    GraemeCAUK
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Joined: 2012/07/05 04:55:02
    • Location: 0
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 08:52:24 (permalink)
    0
    Fair point, but personally I think a warning for an operation consisting entirely of identically typed data is a little excessive. Perhaps it runs a greater risk of overlooking far more serious issues either in the cluttered source code or in the reams of warnings if you choose to ignore them.
    #6
    du00000001
    Just Some Member
    • Total Posts : 1784
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 09:23:35 (permalink)
    +1 (1)
    ... consisting entirely of identically typed data ...

    NO.
    uchar + uchar can easily exceed the uchar range (130+130 > 255).
    Thus the implicit type of the result is not uchar. Applies to other operations in a similar way.
    And overflow is a serious issue in some applications.
    (Even learned once from some overflow compromising SIL applications.)
     
    If you don't like these warnings, you may "disarm" the compiler. Although I'd suggest to embrace them Smile

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #7
    GraemeCAUK
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Joined: 2012/07/05 04:55:02
    • Location: 0
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 09:30:28 (permalink)
    0
    ha ha ... boy is my face red!!!   I think I need to go back to school - I've got my mind on may things today, so not thinking straight.
    #8
    du00000001
    Just Some Member
    • Total Posts : 1784
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 10:08:52 (permalink)
    0
    From time to time it is good to recall the very basics.
    (Hope your face was red from ROFL <gg>)

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #9
    1and0
    Access is Denied
    • Total Posts : 7836
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 10:55:04 (permalink)
    0
    du00000001
    uchar + uchar can easily exceed the uchar range (130+130 > 255).

    OTOH, uint16_t + uint16_t could also easily exceed the uint16_t range.  I also think this warning is excessive and annoying. ;)
     
    Edit: My point is that this
    uint16_t a, b, c;
    c = a + b;

    throws no warning, so this
    uint8_t a, b, c;
    c = a + b;

    should not either.  The compiler can be made smarter. ;)
     
     
    post edited by 1and0 - 2018/03/14 11:21:42
    #10
    jtemples
    Super Member
    • Total Posts : 10741
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 11:04:50 (permalink)
    #11
    1and0
    Access is Denied
    • Total Posts : 7836
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 11:12:12 (permalink)
    0
    mark.pappin
    XC8 generates that message in a number of situations where it arguably should not. We don't yet know precisely why it does (and thus we don't know how we can change the compiler to stop it), which is why it was designated a level "-3" warning, when the compiler's default warning level is "0". But MPLAB X recently changed to explicitly set the compiler's warning level to "-3" so you get the warning now.
     
    You can eliminate many often-bothersome warning messages by changing your MPLAB X project settings to specify a warning level of "-2" (which is the level I have historically recommended as being most helpful while still least distracting). Selecting this level means you will miss out on some useful warnings, but you will also avoid a lot of noise. It's up to you if this tradeoff is acceptable.

    Yeah, too much noise.  The compiler can be made smarter. ;)
    #12
    du00000001
    Just Some Member
    • Total Posts : 1784
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: implicit type conversions with unsigned chars 2018/03/14 11:37:56 (permalink)
    0
    I keep the warning level set to -9 ! And get very little noise.
     
    Maybe a different paradigm: not "smearing" source code but precisely expressing what's to be done.
    Adding some other techniques results in fast, compact code even in free mode.
     
    OTOH, uint16_t + uint16_t could also easily exceed the uint16_t range.

    Yep.
    IIRC, K&R specified another approach on this problem: stepping up to the next-larger data type (availability provided).
    But the ANSI approach with its "warnings side-effects" as described above is the generally-accepted behavior for a compiler when targeting reasonable, low-error count software. (Although I just recently found out that type checking on enums is way below standard for XC8 1.45 - the current version!!!
    Fortunately I had the project set up as some doxygen test project: the doxygen parser complained about assigning enum values from one enum to a variable of another enum type. I really had expected XC8 to check for this - - - failed my expectations sad
     
    There are other "cruelties" these days - e.g. the MISRA warning suppression codes required to suppress static code analysis warnings: in the lower levels of a software you can easily get 3 warnings from a single line of source code. And there is absolutely no way to get rid of these warnings other than suppressing the warning itself.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #13
    Jump to:
    © 2018 APG vNext Commercial Version 4.5