取决于在上下文中这两个数的真实的可能取值范围吧

比如MS的lstrlenA()、lstrlenW()这API由于历史原因定义的返回值类型是int，但实际上一般是不会小于0的（实测了一下，串太长超过INT32_MAX会溢出返回负值），可以直接转为无符号数。最好是不用这种老函数了，尤其是对于不可控的外来输入（自己的输入还能控制不溢出，别人的输入就不一定了），否则就是安全漏洞。

一般情况的话，
1、要先判断有符号数是否为负数，不是负数时再转成无符号数和无符号数比较
2、对来自网络、文件、共享内存、命令行、环境块等的外部输入，慎之又慎，因为你面临的可能是精心构造的畸形数据，一切你认为正常是不可能发生的，都有可能发生
--
修改:z16166 FROM 125.35.123.*
FROM 125.35.123.*

我看到一种说法是除了bit操作、求余这类用unsigned，其他的都用signed。
http://soundsoftware.ac.uk/c-pitfall-unsigned.html

Bjarne Stroustrup本人也认为STL里的size和下标都应该用signed。
目前STL里这些用了unsigned的只是历史上的错误决定。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0.pdf

【 在 ylh0315 的大作中提到: 】
: 都转成long。
--
FROM 125.35.123.*

所以Java后来改了
【 在 ylh0315 的大作中提到: 】
: JAVA就没有unsigned。
: 在加密解密软件里，写一个JAVA和C兼容的算法挺困难。
: 就是求余，二者是不一样的。
: ...................
--
FROM 222.128.176.*

没有加新类型，换了一种方式，是在标准库里给int, long增加了一组无符号算数和比较操作，用起来和汇编有点像。
其实是很早的事了，从java8就有了，现在的lts版本从11都到17了。
【 在 ylh0315 的大作中提到: 】
: 是吗？有unsigned了？
: 【 在 milksea 的大作中提到: 】
: : 所以Java后来改了
: ...................
--
FROM 124.64.16.*

改jvm、改语言是不如改库的。

scala、kotlin也有过unsigned的提案。前者被拒了，说是6%性能降低
https://docs.scala-lang.org/sips/unsigned-integers.html
https://github.com/Kotlin/KEEP/blob/master/proposals/unsigned-types.md

【 在 milksea 的大作中提到: 】
: 没有加新类型，换了一种方式，是在标准库里给int, long增加了一组无符号算数和比较操作，用起来和汇编有点像。
: 其实是很早的事了，从java8就有了，现在的lts版本从11都到17了。
--
FROM 125.35.123.*