+
 新版
2019-09-01 20:00
C的设计原则是赋予程序员最大的控制能力,这就势必带来很大的自由性、使用风险和职业门槛,如果前怕狼后怕虎,或者由于自己学艺不深 无视strncpy最后一个参数 导致使用出问题就怪罪编程语言的话,建议还是改其它语言吧,C语言指针太难、没有gc、没有字符串类型、没有反射...不适合你。但你没资格评价“C是万恶之源”,没资格抱怨“老师傅对你宣讲的C哲学和理念”好像大家在集体骗你一样,如果觉得C语言太low不够范儿,甚至唾弃为上古垃圾语言的,建议不要用Windows、Linux,不要用redis,不要用MySQL、Oracle、MSSQL、PostgreSQL,它们都是C这个上古垃圾语言写出来的,够不上你fashion!我们继续,建议不要用Java、JavaScript、Python、C#、PHP,它们也是用C写出来的!我们继续,建议你写万字控诉书给微软、Linus、甲骨文,一定要从工程实践、数学理论、量子物理、心理史学等全面证明C是垃圾语言,建议用更现代化更fashion的编程语言替代它开发下一代产品!
2019-08-26 22:02
😂全是我喜欢用的。。
2019-08-26 21:43
有很多人总是听不得别人说C不好,好像说C不好,就说明你水平不行一样。
我听够了你不明白C的哲学,C的简洁,C的理念,这些话。
我听够了有的人一边说着可以有节制的使用,一边别人稍微加一点限制就大肆批判一通。

咱就不能老老实实说句真话吗?C的设计没有那么好,它的设计里有一堆坑,这些坑一般都已被熟知(但是其实也没有那么多人清楚)。还记得大明湖畔的gets吗?
2019-08-27 03:26
没错,连标准委员会都新增安全函数了,他们也知道坑有多大。20世纪80、90年代还有过一本《C语言陷阱和缺陷》,显然作者早在几十年前就被坑过无数遍。可惜确实没那么多人清楚坑的存在。
2019-08-27 11:12
请问能简单解释下大明湖畔的gets是什么意思吗?
2019-08-26 21:25
就算使用得当也很容易出问题 这难道不是病句?使用得当也出问题那不是BUG?
2019-08-26 21:33
使用得当,但是每次别人review到这里的时候,都得打起十二分精神,浪费社区的精力,不也是问题吗?以后每次要修改的时候,也更费劲,更容易出错,不也是问题吗?
2019-08-26 20:07
strncpy 都不给用啊,那怎么拷贝字符串???
2019-08-26 21:28
微软的方案是strncpy_s,OpenBSD的方案是strlcpy,GLIBC的“方案”是strlen + memcpy。
strncpy有两个问题,第一,它可能会导致字符串末尾没有NUL(之后哪怕一个简单的strlen也会越界);第二,它会有性能问题,因为它会(不必要地)把缓冲区的末尾填满NUL,比如缓冲区是4096字节,哪怕源字符串为空,它也会把4096填满NUL。
2019-08-29 11:21
strlen+memcpy第一个问题不是一样存在吗,都是控制不好内存size导致的问题
2019-08-26 19:50
C是万恶之源
2019-08-26 11:56
sprintf可以理解,strncpy怎么就不安全了,不能一刀切啊
2019-08-26 18:03
strncpy可能会导致目标字符串没有null结束符。当源字符串,在前n个字符中不包含null结束符时,这里的n是指strncpy里面的最后一个参数。
2019-08-27 12:08
sprintf是没办法控制越界,strncpy已经加了参数机制让程序员控制越界,程序员不正确使用就是程序员的问题了,你总不能说程序员不正确理解或不认真马虎写出有问题的代码都是语言设计问题吧?
2019-09-01 20:47
strncpy不会,也不应该在复制前面n个字符完了之后补上0,导致每次使用strncpy截取源字符串部分字符时,都需要程序员要么在初始化的时候指定零初始化,要么在复制之后手动后补0,那么在给定一段代码之后,如果没有上下文和具体需求,就没有办法得知这段代码想要做的是什么,有可能是拼接字符串而不补0,有可能是直接取部分字符串,也有可能是忘了补0,这就是问题所在
2019-08-26 11:07
这个不是应该加在ci的静态代码检查里面吗,调用之后触发ci自动回退
2019-08-26 11:20
放在ci里做检测是后知后觉,代码已经提交了。层面不一样。
回复 @
{{emojiItem.symbol}}
返回顶部
顶部