|
In your new code, in order to not get the warning, this:
~(clr_flags)
...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 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...
Simon
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.
Ray
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:
<http://savannah.nongnu.org/bugs/?54190>
_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/
|