Polyspace 发出关于系统函数使用系统定义参数标志的警报答案

【问题标题】：Polyspace alerts about use of system-defined parameter flags for system functionsPolyspace 发出关于系统函数使用系统定义参数标志的警报
【发布时间】：2018-11-19 16:33:48
【问题描述】：

我正在使用 Polyspace Code Prover 和 Bug Finder 对我用 C 编写的 Linux 应用程序执行静态分析。

我们收到了几个关于使用上述调用的“手册”页面定义的标志的警报。在 open()、write() 或 syslog() 等函数的手册页中，我们可以看到它们有一个参数，我们可以将其作为接口定义的多个标志的 OR 传递，如下例所示：

fd_value = shm_open(shm_key, O_CREAT | O_RDWR | O_EXCL , S_IRWXU);

Polyspace 抱怨说，在上面的示例中，标志 O_CREAT、O_RDWR 和 O_EXCL 属于不同的基本类型（一些无符号，一些有符号），因此不建议使用这种 OR 操作。根据 MISRA 的 10.1 指南，这是正确的，但如果这是系统定义其 API 及其值的方式，我能做些什么呢？在我看来，仅仅为了让工具快乐而铸造价值是有风险的。

除了为这些违规行为辩护之外，还有其他解决问题的方法吗？

谢谢你，最好的问候！

【问题讨论】：

如果你通过演员阵容“作弊”会发生什么？例如。 shm_open(shm_key, (int)((unsigned)(O_CREAT) | (unsigned)(O_RDWR) | (unsigned)(O_EXCL)), S_IRWXU);。我猜，这些函数/值是在int 和unsigned 在位算术中的差异被认为不那么难的时候定义的。 ;-)
我不认为 Linux 和 MISRA-C 会彼此相爱。本质上你是在问：为什么shm_open 写得像废话？好问题。获得这些枚举的不同符号需要一些相当大的混淆技巧，特别是因为标准 C 要求枚举常量的类型为 int 并且该函数将 int 作为参数。
@JorgeJuanTorresQuiroga 对于“核心”MISRA-C 实现，您不允许项目中的任何 C 代码不遵循 MISRA-C，包括库。对于“MISRA-C light”，您可以例外。大多数情况下，这取决于应用程序是否实际上是任务关键型应用程序，或者您是否只是使用 MISRA-C 作为消除错误的标准来提高质量。如果是前者，答案很简单：这个库不能用于这个应用程序，因为它写得很草率。
@JorgeJuanTorresQuiroga 是的，在这种情况下，使用此特定功能可能是最好的方法。
标准库充满了糟糕的代码，这些代码“有效”——但并不像它应该的那样“正确”。 MISRA 合规性试图帮助采用的代码，但在标准“正确”定义事物之前，我们都会遇到这些问题:(

标签： c static-analysis misra

【解决方案1】：

这些值是用不同的符号定义的，这有点奇怪。添加一个平台隔离层可能是个好主意，它将这些常量重新定义为特定于模块的常量，执行必要的转换并可能处理跨平台差异。

typedef int t_my_shm_open_flags;

#if(defined(PLATFORM1))
#define MY_SHM_OPEN_FLAG_CREATE     ((t_my_shm_open_flags) O_CREAT)
#define MY_SHM_OPEN_FLAG_READ_WRITE ((t_my_shm_open_flags) O_RDWR)
#define MY_SHM_OPEN_FLAG_EXCLUSIVE  ((t_my_shm_open_flags) O_EXCL)
#else
/* error for unsupported platform */
#endif

#define MY_SHM_OPEN_DEFAULT_FLAGS (MY_SHM_OPEN_FLAG_CREATE | MY_SHM_OPEN_FLAG_READ_WRITE | MY_SHM_OPEN_FLAG_EXCLUSIVE)

【讨论】：

原因很可能是库代码中的设计缺陷。我们不应该需要产生肮脏的黑客来按预期使用函数。