[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] [bug #54190] Minor compile warnings under newly-release

From: Ray Ozzie
Subject: Re: [lwip-devel] [bug #54190] Minor compile warnings under newly-released IAR EWARM 8.30.1
Date: Mon, 2 Jul 2018 19:09:29 +0000

In your new code, in order to not get the warning, this:
...needs to be either a) masked to the number of significant bits of the target (ie 8 or 16 as the case may be), or b) cast to the data type of the target. 

On Jul 2, 2018, at 2:37 PM, "address@hidden" <address@hidden> wrote:

On 02.07.2018 17:04, Ray Ozzie wrote:
I don't know if this is precisely how you would have made the changes, but attached are four files based on 2.0.3 that do successfully eliminate the warnings.

After testing, I found that I could eliminate the warning either by a) masking with an appropriate mask, or b) casting to the appropriate data type.

The code has changed since 2.0.3. We now have

#define          tcp_clear_flags(pcb, clr_flags)   do { (pcb)->flags = (tcpflags_t)((pcb)->flags & ~(clr_flags)); } while(0)

(for udp, it's nearly the same). So would this work (not the cast to tcpflags left to the ~):

#define          tcp_clear_flags(pcb, clr_flags)   do { (pcb)->flags = (tcpflags_t)((pcb)->flags & (tcpflags_t)~(clr_flags)); } while(0)

Or do we need something else? I'd prefer that to the _FLAGS suffix AND thing...


Since I found other places in the code that defined symbols with a suffix _FLAGS that represented "all possible flags", I went with that approach under the assumption that this would be your preference.

Thank you for your consideration.


On 6/28/18, 3:25 PM, "Simon Goldschmidt" <address@hidden> wrote:

    Follow-up Comment #3, bug #54190 (project lwip):
         On 27.06.2018 22:12, Ray Ozzie wrote:
    > I apologize for not being able to make this easier.
    > Although I haven’t tested any fixes myself, it appears that the core issue
    is the technique of generating a ~ mask from a constant (Ie interpreted by the
    compiler as size_t or whatnot), and then assigning the masked value into
    something smaller (ie uint8) is flagged as potentially losing significant
    bits. I believe a cast may be needed on all these mask ops.
    > If you have anything you’d like me to try, I’m happy to take the fix and
    tweak it as necessary and get it back to you.
    > Thanks much.
         Reply to this item at:
      Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]