第三道嵌入式系统功夫题

只看该作者 · 2008-2-27 11:18

char *buf;
函数verify用于校验buf中头4个字节的内容是不是'ABCD'4个字符
bool verify(char *buf)
{
uint32 a=0x44434241;
return ((*(uint32 *)buf) == a);
}
要求函数verify能在各种嵌入式环境中移植。
问题：
1、verify函数正确吗？
2、在什么环境下是正确的？
3、在什么环境下是不正确的？
如果第3个问题列举两类或以上环境，说明你已经有嵌入式开发的中级功力了。

补充：
好像高手们都不屑于研究此类问题，但这可不同于奇技淫巧，它可有效降低产品中潜在的bug，尤其对于嵌入式操作系统或者中间件的作者，意义非凡，你总是希望自己写的操作系统或者中间件能够适应更多的CPU！

1万 · 2008-2-27 11:22

只看该作者 · 2008-2-27 11:25

“如果第3个问题列举两类或以上环境，说明你已经有嵌入式开发的中级功力了。”
看仔细了，两类以上，你已经答对了一类了。

只看该作者 · 2008-2-27 11:29

只看该作者 · 2008-2-27 11:31

又答对一类，看还有没有继续的？

1万 · 2008-2-27 12:04

2万 · 2008-2-27 16:38

连基本的可读性和可理解性都不符，更不用说可移植性了。
LZ：嵌入式系统功夫如果在于你所出的那些题也太误导人，太可笑了。还是早些罢了，踏踏实实地埋头看些书干些实事吧。

只看该作者 · 2008-2-27 17:18

    这个问题是从一个资深工程师所犯的错误中抽象出来的，而且错误果然作为一个bug潜伏在产品中，运行若干年后爆发，花了巨多的钱才搞定。原来的代码太长，这段代码是临时捏的，可读性是差了点，但还能看懂，不是吗？
    所以，这绝不是茴字写法的问题。我出的这几道题，都是从别人（还好，不是我）犯过的错误中抽象出来的，有些错误还是造成了巨大损失的。这些东西是从实际工作中发现的，书上好像没有。
第一道题的错误原型：有人函数内数组溢出导致母函数局部变量被修改，并戏称发现了一个修改母函数局部变量的方法。
第二道题的错误原型：有一linux熟手（他自认为高手）非要用uclinux做实时应用。

    这几天比较闲，上坛子兴风作浪来了。

2万 · 2008-2-27 19:09

只看该作者 · 2008-2-27 19:40

吸取错误的教训，可以不犯同样错误。
升华并研究错误，可以不犯同类错误。

2万 · 2008-2-27 19:52

甚至于都不能称之为错误，简直是概念混淆。

2万 · 2008-2-27 20:03

分析,

先把基本理论写上:
int *p; 　　　 p为指向整型量的指针变量
int *p[n]; 　　p为指针数组, 由n个指向整型量的指针元素组成。
int (*p)[n]; 　p为指向整型二维数组的指针变量, 二维数组的列数为n
int *p() 　　　p为返回指针值的函数, 该指针指向整型量
int (*p)() 　　p为指向函数的指针, 该函数返回整型量
int **p 　　　 p为一个指向另一指针的指针变量，该指针指向一个整型量
标识符右边的方括号和圆括号优先于标识符左边的"*"号, 而方括号和圆括号以相同的优先级从左到右结合.

阅读组合说明符的规则是"从里向外": 从标识符开始, 先看它右边有无方括号或园括号, 如有则先作出解释, 再看左边有无*号. 如果在任何时候遇到了闭括号, 则在继续之前必须用相同的规则处理括号内的内容. 例如:
int *(*(*a)())[10];
↑ ↑↑↑↑↑↑
7 6 4 2 1 3 5
上面给出了由内向外的阅读顺序, 下面来解释它:
(1)标识符a被说明为;
(2)一个指针变量, 它指向;
(3)一个函数, 它返回;
(4)一个指针, 该指针指向;
(5)一个有10个元素的数组, 其类型为;
(6)指针型, 它指向;
(7)int型数据.
因此a是一个函数指针变量, 该函数返回的一个指针值又指向一个指针数组, 该指针数组的元素指向整型量.

1万 · 2008-2-27 20:05

2万 · 2008-2-27 20:09

return ((*(uint32 *)buf) == a);
(*(uint32 *)buf)
*(uint32 *)buf
可以看出, 是把buf强制成指向uint32的指针. 然后又取值.

好, 可以答题了.
1、verify函数正确吗？
一定环境下正确(不用分析也知道..)
2、在什么环境下是正确的？
答: 1, 传递的buf指向的值是4的倍数, 不然就溢出.
2, ....

djyos 前辈公布答案啊

2万 · 2008-2-27 20:11

这两天没来, 不知第道题在什么地方

3万 · 2008-2-27 20:12

2万 · 2008-2-27 20:14

2万 · 2008-2-27 20:23

这些内容都是我收集了好久的, 是实际中遇到的, 不然我也不总结这玩意.

如果你看linux得源代码的话, 你会看到很多这玩意, 比这复杂的还有.

"从软件工程的角度来看一堆垃圾"

现在软件模块化, 快速化, 确实是这样的, 但是对底层编程, 用C, 特别是看高手的C程序, 这些知识还是需要的, 不然, 无法成长为顶级的高手

2万 · 2008-2-27 20:27

2万 · 2008-2-27 20:31

比如, 您认为该如何处理该问题呢?

第三道嵌入式系统功夫题

相关下载

相关帖子

大小端问题

圈圈加油

对齐问题。

dld2加油

呵呵,学习了

毫无价值，从软件工程的角度来看一堆垃圾。

7楼上不要太武断

所以，我说这是一堆垃圾没错啊。

垃圾论者，如果你不认为错误是正确之母的话……

问题是这错误太低级，更和所谓的“嵌入式系统功夫”无关

有了第一道题的功底, 试着答一下

还是支持楼主,做老师应该 心态平和点啊

接续分析

顺便问一下第2道题呢?

同感，连数组都可以溢出，谈其它显然是未走先飞了

看了12楼更是无语，服了。呵呵，该我罢了。

给HWM的一点意见

再次无语！

那请HWM发表一些实质性的意见

永恒之光奖章

技术导师奖章

七世轮回

坚毅之洋流

以坛为家

精英会员奖章

奔腾之江水

技术高手奖章

荣誉元老奖章

十世金身

技术领袖奖章

核心会员奖章

还是支持楼主,做老师应该心态平和点啊