object.c 中 rt_object_find 的修改存在 bug about rt-thread HOT 11 CLOSED

补充的那个场景在 utest 复现了。

定位了一下，是因为一开始没考虑到 &object->name == object 的情况。 方便的话也拜托你验证一下。db404db

可以了
这个iterate的语法糖感觉没什么必要

from rt-thread.

Cannot re-produce on #8959

@liuyangzys

from rt-thread.

建议先检查你的工程中是否存在栈溢出问题。

from rt-thread.

Sorry, 我没有仔细分析我遇到的问题，描述的有误。 但 bug 应该是存在，我对比了一下提交修改，以下是分析

rt_object_find 函数判断

本意是判断需要 name 和 obj.name 不是同一个地址才会返回对象地址。

但如果用 rt_device_find(device.parent_obj.name) 这样的方式去寻找 dev, 将会失败返回 RT_NULL
例如 shell.c 中491 行

更新了改 commit 后我发现控制台无用了，当时测试了以下用常量字符串可以找到需要用控制台的串口，没有仔细分析就来提问了

我不了解为什么 rt_object_find 中最后需要这个判断。如果一定需要该判定，那我们应该去修改 shell.c 中的 rt_device_find 的引用方式，并在以后所有的使用中都要注意不能用 rt_device_find(device.parent_obj.name)这样调用方式

from rt-thread.

本意是判断需要 name 和 dev.name 不是同一个地址才会返回对象地址。

并不是。是判断 name 是否匹配，然后被更新。

from rt-thread.

本意是判断需要 name 和 dev.name 不是同一个地址才会返回对象地址。

并不是。是判断 name 是否匹配，然后被更新。

看看吧。我在更早的rtt版本上运行是正常的。这个commit 跑到 fins_set_device(console.parant.name) 就是有问题。不管是 uart1 还是 vcom

这个接口是 RTT的重要接口, 麻烦多考虑一下

from rt-thread.

补充的那个场景在 utest 复现了。

定位了一下，是因为一开始没考虑到 &object->name == object 的情况。
方便的话也拜托你验证一下。db404db

from rt-thread.

我不了解为什么 rt_object_find 中最后需要这个判断。如果一定需要该判定，那我们应该去修改 shell.c 中的 rt_device_find 的引用方式，并在以后所有的使用中都要注意不能用 rt_device_find(device.parent_obj.name)这样调用方式

原本的意思是复用一个地址来存参数 name 和匹配对象 obj。如果假定两个对象地址不会重名，那么这个地址被更新就说明匹配成功。不过之前没考虑到 rt_object 的 name 也放在 obj 起始地址上，所以 name 和 obj 两个指针有可能相同的情况。

from rt-thread.

顺便吐槽一下，拿到 object 还要用 object->parent->name 去找设备，这使用场景真的有点怪 😂

from rt-thread.

这个iterate的语法糖感觉没什么必要

第一，rt_object_for_each 有实际引用的，对应于场景{匹配所有符合某种模式的设备，如 ttyS\d+}。
第二，基于上述原因，rt_object_find 与 rt_object_for_each 其实就可以找到公共子流程。
既然如此，拷贝两份代码是冗余的。

from rt-thread.

#8959

from rt-thread.