- 主题:上午面试了一个小孩，问了一个问题是不是太过分了 (转载)
这种代码就不应该被允许合并，你明明知道这个跟编译器强相关，还要把字符型强行赋值有符号整型，静态代码分析居然不会给你扔个error过来？
【 在 anotherstone 的大作中提到: 】
: 发信人: feiy (null), 信区: NewExpress
: 标 题: 上午面试了一个小孩，问了一个问题是不是太过分了
: 发信站: 水木社区 (Thu Jul 8 18:25:14 2021), 站内
: ...................
--
FROM 219.142.54.*
这肯定时直接不上分析工具，因为错误报警一大堆，还不知道怎么解决，所以干脆不解决，大家一直错着来。
【 在 comus 的大作中提到: 】
: 关键这种问题没意义，现在代码有lint，有gcc warning检查，年轻人不懂也没关系，都会查出来的。
: 另外所有代码不应该不能用char_t，int32_t之类的代替char ，int的使用吗？（这个lint也能查出来）
: 而且，你的代码既然写的是-5，按你说的char被编译器当成uchar的话。编译能通过，我也是醉了…
: ...................
--
FROM 219.142.54.*
当然能管住啊，上个静态代码分析，合并之前分析代码，通过才给合。还要做公开review
【 在 hgoldfish 的大作中提到: 】
: 能管住自己的手，管不住别人的手啊。
:
--
FROM 219.142.54.*
那你考虑过，为啥这种低级坑还需要你去翻书记好几次么？如果有一百个程序员，搞这种坑，成本多少钱？效率呢？
为啥不从根本上杜绝这种垃圾代码？
【 在 mystar1984 的大作中提到: 】
: 顶楼主一个，虽然这个是不良编程风格的坑，但确实是一个知识点。
: 又翻了下书，再记一次。
: 经验就是这么来的。
: ...................
--
FROM 219.142.54.*
几十K内存的SoC大把
【 在 JulyClyde (我的月份又来了) 的大作中提到: 】
: agLee
: agLee
: 我比较怀疑限制这种1MB的环境是不是真的还存在。现在SoC自带的内存也不止这些吧
: ...................
--
FROM 122.225.220.*
这种要出货量很大的话才划算吧？
出货量小的话，用这种 SOC 会不会太浪费开发资源了。
【 在 adoal (阿豆) 的大作中提到: 】
: 几十K内存的SoC大把
--
FROM 110.81.41.*
size_t不是单位。
单位的意思是，如果char是32位，那么memcpy(_,_,1)拷贝了多少位数据？
【 在 JulyClyde 的大作中提到: 】
: 这几个不都是以size_t为单位吗？？
--
FROM 114.86.93.*
所以写出一堆潜在bug的代码，掉坑里，解决后就说长经验了，美其名曰经验丰富。浪费时间在这自我陶醉的技巧上，小项目无所谓，花点时间还能整吧整吧，大项目搞到最后直接挂掉。
大公司还是靠谱点，有各种代码检查
【 在 zhbzhang 的大作中提到: 】
: 这肯定时直接不上分析工具，因为错误报警一大堆，还不知道怎么解决，所以干脆不解决，大家一直错着来。
:
: 【 在 comus 的大作中提到: 】
: ...................
--来自微水木3.5.11
--
FROM 120.245.128.*