为什么container_of不在glibc中?

发布于 2024-10-31 03:02:11 字数 68 浏览 1 评论 0原文

是否有技术原因导致 libc/glibc 中的 container_of() 可能不被接受?

谢谢, 陈兹

Is there a technical reason why container_of() may not be acceptable in libc/glibc?

Thanks,
Chenz

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

少钕鈤記 2024-11-07 03:02:11

有无数的宏和函数不存在于 C 库中——不需要有任何理由不存在其中任何一个,并且 Linux 内核的 container_of 宏的实用性有限。但是,我认为没有任何技术原因无法在 stdlib.h 中将其定义为

#define container_of(ptr, type, member) (type*)((char*)(ptr) - offsetof(type, member))

There are an infinity of macros and functions that aren't in the C library -- there doesn't need to be a reason why any one of them isn't there, and the Linux kernel's container_of macro has limited utility. However, I don't think there's any technical reason why it couldn't be defined in stdlib.h as

#define container_of(ptr, type, member) (type*)((char*)(ptr) - offsetof(type, member))
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文