免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: HopeCao
打印 上一主题 下一主题

出现频率最高的笔试题strcpy写法 [复制链接]

论坛徽章:
0
41 [报告]
发表于 2008-09-27 17:26 |只看该作者
其实这就是一种吃饱了撑的的编程态度。

程序的正确,是靠逻辑来保证的。作为strcpy的调用者,你必须对你自己的行为负责,即保证传入参数的正确性。

想象一下,这个strcpy是在一个循环中的情况。如果每次都进行这些判断的话,要浪费多少CPU资源?

所以,既然strcpy是由用户来提供目的地址,当然由用户来保证目的地址有效、正确、不溢出。

出这个题目的公司,出题者有问题。

论坛徽章:
0
42 [报告]
发表于 2008-09-27 20:38 |只看该作者
原帖由 benjiam 于 2008-9-27 13:45 发表



毫无意义的例子, 神州7号,运行过程中发现有问题,不是返回错误,启动应急方案。 而是让他crash 掉,让他直接掉下来。

返回错误 也是可以找到错误 恢复工作的。


crash 掉正是为了通知外界立即启动应急方案。如果带着异常继续运行才会导致某个时刻悄无声息的掉下来

论坛徽章:
0
43 [报告]
发表于 2008-09-27 20:42 |只看该作者
原帖由 思一克 于 2008-9-27 16:11 发表
还有,
不要将应用程序的CRASH(Segmentation fault后推出运行)理解成汽车撞树,飞机CRASH地面.

实际上, 这里发生的一切都在OS 的掌控之下,检查出问题了,让你的程序停止下来, 温柔地停下来.
有点相当与你靠驾 ...


对!

论坛徽章:
0
44 [报告]
发表于 2008-09-27 20:48 |只看该作者
原帖由 benjiam 于 2008-9-27 13:55 发表


其实我也一直在反思这个问题。  发现参数错误了 到底是应该善意的返回一个错误码 还是应该不检查 crash 掉。


其实2中方式都是合理的,问题的关键是接口的定义:接口约定为按第一种方式实现,那就返回错误码;接口约定为按第二种方式实现,那就由调用者保证参数的正确性。
作为几乎最底层api的strcpy, 显然应该采取第二种方式

论坛徽章:
0
45 [报告]
发表于 2008-09-27 20:52 |只看该作者
原帖由 ytl 于 2008-9-27 20:48 发表


其实2中方式都是合理的,问题的关键是接口的定义:接口约定为按第一种方式实现,那就返回错误码;接口约定为按第二种方式实现,那就由调用者保证参数的正确性。
作为几乎最底层api的strcpy, 显然应该采取第 ...


你的这句话很有道理:
其实2中方式都是合理的,问题的关键是接口的定义:接口约定为按第一种方式实现,那就返回错误码;接口约定为按第二种方式实现,那就由调用者保证参数的正确性。

论坛徽章:
0
46 [报告]
发表于 2008-09-27 20:56 |只看该作者

回复 #45 system888net 的帖子

而且两者是可以结合起来的.也就是CRASH和返回值可以在不同情况下结合起来用. 取其长而避其短.

论坛徽章:
0
47 [报告]
发表于 2008-09-27 20:56 |只看该作者
原帖由 ytl 于 2008-9-27 20:48 发表


其实2中方式都是合理的,问题的关键是接口的定义:接口约定为按第一种方式实现,那就返回错误码;接口约定为按第二种方式实现,那就由调用者保证参数的正确性。
作为几乎最底层api的strcpy, 显然应该采取第 ...



可以这样简单的总结:对于一个系统的内部,应该尽可能由调用者保证参数的正确性;而对于系统与系统之间的接口,则实现者必须检查参数的有效性,应该力求作到对于任何输入,自己都不会crash。strcpy()是前者的一个例子。对于后一种情况,考虑系统调用:无论任何参数,os内核绝对没理由crash;再有web server的例子,无论浏览器向server发送了多么不合理的请求,web server都不应该crash

论坛徽章:
0
48 [报告]
发表于 2008-09-27 21:01 |只看该作者
原帖由 ytl 于 2008-9-27 20:56 发表



可以这样简单的总结:对于一个系统的内部,应该尽可能由调用者保证参数的正确性;而对于系统与系统之间的接口,则实现者必须检查参数的有效性,应该力求作到对于任何输入,自己都不会crash。strcpy()是前 ...


good, 说的非常客观!

论坛徽章:
0
49 [报告]
发表于 2008-09-27 21:16 |只看该作者
楼主真的很高!!!

论坛徽章:
8
CU大牛徽章
日期:2013-04-17 10:59:39CU大牛徽章
日期:2013-04-17 11:01:45CU大牛徽章
日期:2013-04-17 11:02:15CU大牛徽章
日期:2013-04-17 11:02:36CU大牛徽章
日期:2013-04-17 11:02:58技术图书徽章
日期:2013-12-04 10:48:50酉鸡
日期:2014-01-03 10:32:30辰龙
日期:2014-03-06 15:04:07
50 [报告]
发表于 2008-09-28 09:23 |只看该作者
我来补充一点:

内存访问违例,在linux下会导致OS给你发一个sign 11

如果你捕获了这个sign 11并内置机制妥善处理了它(比如,可以使用setjmp/longjmp,或者干脆用C++提供的现成品try-catch),那么程序显然是不会崩溃的:这是正确且唯一正确的做法。


请用GDB打开所有因为内存访问违例导致crash的core,你会发现程序崩溃的原因不是因为内存访问违例,而是没有处理sign 11,从而导致处理流程跑进系统内置的core dump例程之中



sign 11并非唯一可用的手段——如果深入了解过操作系统的话。

如果感觉不能理解的话,请去查查资料,搞明白CPU执行某指令,发现它访问无效内存或除零错、溢出等等发生后,继而发生的一切细节。

我们一直强调程序有bug就让它crash,原因就在于我们有无数的后续手段,可用以保证代码 总体 的稳定。

隐藏错误去严防crash,代码 局部 看来是稳定了——但 总体 质量必定会是一坨屎。

[ 本帖最后由 shan_ghost 于 2008-9-28 09:31 编辑 ]
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP