任何人都可以提供Misra C++合规' Offsetof'与static_assert一起使用的宏/模板/函数?
我正在尝试编写防御代码,并提出static_assert>
,以确保结构的成员具有特定的偏移,以满足某些硬件要求
Misra C ++规则18-2-1说:可以使用”,所以我们已经淘汰了。
我们提供了一些模板内容,但是当在static_assert<>
中使用时,它们都失败
了代码>跨编译器。
struct Commands
{
uint32_t command[4];
};
struct DMA_Bundle
{
struct header_
{
uint32_t num_of_elems;
uint8_t reserved[60];
} header;
Commands array[16];
};
我试图确保array
从一开始就为64个字节。
static_assert(offsetof(DMA_Bundle,array)==64,"zoinks");
确实有效,但米斯拉说,但我不能使用它。 (而且我不能与我们的功能安全人员争论:/)
我已经尝试了以下操作,并且通常不起作用:
static_assert(offsetofarray()==64,"bar");
static_assert(myoffsetof(DMA_Bundle::array)==64,"double_zoinks");
显式OffSetOfArray()
constexpr函数在GCC 7.5下确实有效。 0,但在后来的GCC和Clang(这是我们嵌入的处理器工具使用的用途)下。它失败了,“ static_assert的非恒定条件”。
另一个似乎抱怨“非静态数据成员的使用无效的DMA_BUNDLE :: ARRAY'”,
并且,对于它的价值,我仅限于C ++ 11。
I'm trying to write defensive code and put static_assert<>
to ensure a structure's member has a specific offset to satisfy some hardware requirements
MISRA C++ Rule 18-2-1 says "The macro offsetof shall not be used", so we've 'undef'd offsetof.
We've provided some template things, but they all fail when used in static_assert<>
I've been unable to find something that works with C++11 static_assert<>
across compilers.
struct Commands
{
uint32_t command[4];
};
struct DMA_Bundle
{
struct header_
{
uint32_t num_of_elems;
uint8_t reserved[60];
} header;
Commands array[16];
};
I'm trying to assure that array
is 64 bytes from the beginning.
static_assert(offsetof(DMA_Bundle,array)==64,"zoinks");
Does works, but MISRA says but I can't use that. (and I can't argue with our functional safety people :/)
I've tried the following, and generally they don't work:
static_assert(offsetofarray()==64,"bar");
static_assert(myoffsetof(DMA_Bundle::array)==64,"double_zoinks");
The explicit offsetofarray()
constexpr function does work under GCC 7.5.0, but it fails under later GCC and Clang (which is what our embedded processor tools use). It fails with 'non constant condition for static_assert'.
The other seems to complain of "invalid use of non-static data member 'DMA_Bundle::array'"
And, for what it's worth, I'm limited to C++11.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
一些背景:
,这是您的第一个问题...
Misra C ++:2008仅允许使用C ++:2003-此后的任何内容都超出了范围。
使用
#undef
是违反必需规则16-0-3(并且不需要#undef> #undef Offsetof
)现在要解决要点:
规则18-2-1是A 必需的规则,它试图在操作数类型不兼容时不确定的行为。
许多剪贴板监视器的问题是他们可以打勾,但是如果不了解米斯拉实际上说什么……
我的建议,尤其是在相关联时才使用的情况下, 采用“米斯拉说不的”态度使用
static_assert()
是提高偏差(请参见第4.3.2节和Misra合规性中的扩展指导)。偏差是一种完全合法的方法,其中规则可能会造成不便,但不适用不确定的行为不适用。
ETA(指出与lundin关于c的讨论):在Misra C:2004中,有一个同等准则(规则20.6),同样对
Offsetof
- 在Misra c:2012中施加了毯子限制。 在许多方面捕获的一般规则1.3捕获的不确定的行为下降,这使得Misra C ++偏差的正当性更容易 - 因为理由将与Misra C的决策相匹配。
请参阅分支机构的个人资料
Some background:
And here is your first problem...
MISRA C++:2008 only allows the use of C++:2003 - anything after this is out of scope.
Use of
#undef
is a violation of required Rule 16-0-3 (and it is unnecessary to#undef offsetof
)Now to address the main point:
Rule 18-2-1 is a required Rule which seeks to protect against undefined behaviour when the types of the operands are incompatible.
The problem with many clip-board monitors is they can tick boxes, but adopt a "MISRA says no" attitude without understanding what MISRA actually says...
My suggestion, especially if only being used when associated with
static_assert()
is to raise a deviation (see section 4.3.2 and the extended guidance in MISRA Compliance).A deviation is a perfectly legitimate approach, where a Rule may be causing an inconvenience, but the undefined behaviour is not applicable.
ETA (noting discussion with Lundin about C): In MISRA C:2004, there was an equivalent guideline (Rule 20.6) which likewise imposed a blanket restriction on
offsetof
- in MISRA C:2012 this blanket restriction was dropped, with the undefined behaviour captured by the general Rule 1.3In many respects, this makes justification of a MISRA C++ deviation easier - as the rationale would be matching the MISRA C decision.
See profile for affiliation