there may be a saner fix involving a cast to an integer as long as you know that the range checks will still work properly... or use a variable of the correct type instead?
I run into this kind of signed/unsigned comparison warning a lot with microcontrollers that have 8 bit unsigned integers as counters for "reasons" (like speed+range). I usually just type-cast the warnings away and make sure the code is sane. It's good to hand-optimize microcontroller code anyway.
NOTE: magic numbers in code should use #define or a 'const' type anyway, so you could fix it in the definitions.
and with the original argument
"if(thingy >= 0 && thingy <= llmit)"
where 'thingy' is unsigned, and you know it is unsigned, why leave the '>=0' in the actual code? At least use a comment if you need it there for some reference type of reason, maybe:
"if(/* thingy >= 0 && */ thingy <= limit)"
(then add a comment that says 'thingy is unsigned' or similar)
I sometimes do this with an ending 'else', comment out an 'if' following it that indicates the condition in the 'else' if the 'if' would always be true (and also indicate in the comment that it's always true), so that someone reading the code (including me a year later) will see that and go "ok".