这个问题扯起来就复杂了。比如我用别人的代码都会先过下，把隐藏问题处理下，把雷排一排。
但这样会有额外投入，还会有额外风险，比如引入新的问题等等。

大部分人的做法是管它这么多呢，按照原来的代码要求的系统，环境，版本，什么都不改精确的搭一个的跑。
这也是docker普及之后大家越来越喜欢的玩法。然后多代码之间的联动协作又开始成为了新的麻烦。

这是一个理念的问题。对于你的这个场景，我倾向与先彻底消除char这种用法。
如果有多个库都自己定义的u8 s8，需要处理多个库之间的数据传输和格式转换，那就把所有的库都处理成统一的格式。

总之，我的基本思路是基础牢靠很重要，与其靠个人实力在危楼里面搭鹏，不如费点力气把地基打好，按规矩建设。
这笔额外的投资是必须要支付的代价，尤其是如果这个东西是构成你公司核心竞争力的产品的话更应该如此。

至于什么工程是意外使用之类的，这种事情有一万种解决办法。比如编译器给warning的代码不让push到repo就结束了。

【 在 feiy 的大作中提到: 】
: 所以，规范公司和有经验的工程师都会拒绝用单独一个char(plain char)，都会定义一套u8  s8 u16 s16之类的使用。
: 但现实里，却是有不少工程师有时会无意该地夹杂用char来表示他所本意的signed 8-bit，而且认为没错无问题。有时候，编译器会给warning，有时候未必会给warning(前面有人说char a=-5；很易被warning，但若-5是隐性计算出来的呢，编译器本身也并不总是很聪明)，有很多人面对一大堆warning也习惯于忽略无视。
: 不是说一定会出问题bug，做多开发经验有了，一般基本都会遇到。
: ...................
--
修改:lvsoft FROM 180.111.50.*
FROM 180.111.50.*