tb_strcmp bug

[wzy2687]

tb_strcmp("abc", NULL) will return 0;

[wzy2687]

// version
#define TB_CONFIG_VERSION "1.6.3"
#define TB_CONFIG_VERSION_MAJOR 1
#define TB_CONFIG_VERSION_MINOR 6
#define TB_CONFIG_VERSION_ALTER 3
#define TB_CONFIG_VERSION_BUILD 201904191123

[waruqi]

再试试 dev

[wzy2687]

再试试 dev

收到. 迟点测试.

[wzy2687]

再试试 dev

测试dev. tb_strcmp("abc",NULL) 和 tb_strcmp(NULL,"abc") 都会返回-1.
如果用 strcmp("abc",NULL), 程序会异常退出.

@waruqi

[waruqi]

正常，返回 -1 比较失败，debug 模式会触发 assert 抛异常 并dump 栈

[wzy2687]

正常，返回 -1 比较失败，debug 模式会触发 assert 抛异常 并dump 栈

如果有null 传入, 能否直接异常退出. -1 也是代表小于的意思. 程序可能会在后面挂, 或者出现未知行为.

[waruqi]

所以目 debug 模式会触发 assert 也会抛异常提前中断。

release 下并不是所有的业务场景都能够接受，非法参数 0 容错，直接崩的。

如果是服务端程序，当然可以直接提前崩了，提前发现问题，今早解决，修完大不了直接重启更新下服务。

但是对于客户端程序，像 ios/android 等端上，上亿用户量，ios app 更新上架修复的迭代周期很长，也不支持热修，就算非法传参，即使部分业务异常，也不能让它直接崩，大规模线上崩溃更严重，而且没法立马修。

否则随便一次非法传参，就让它导致线上大面积崩溃了，那就可以直接跑路了。

目前这边策略就是折中处理，release 模式尽可能不崩，所以 tbox 大部分入口参数都有 check ，但是在 debug 模式，还是可以通过 assert 尽可能提早发现问题

[wzy2687]

确实, 应用场景不同,处理方式不同, 有没有这种可能. 把参数检查什么作为一种配置, release 的时候也能检查. 我这边场景比较小众, 基本要求是: 正确运行, 不正确就尽快挂掉.

[waruqi]

目前没有，现在只能debug 下如此，除非你 release 下强开 __tb_debug__ 宏。库外面的代码，可以自己用 tb_check_abort 每次强制中断