在这个 lint 错误抑制尝试中我做错了什么？还有更好的方法吗？答案

【问题标题】：What am I doing wrong in this lint error suppression attempt? And is there a better way?在这个 lint 错误抑制尝试中我做错了什么？还有更好的方法吗？
【发布时间】：2014-07-11 17:56:51
【问题描述】：

我有以下代码行：

ftDCB.ByteSize = FT_BITS_8;

而 lint（特别是通过 Visual Lint 的 PC-lint）给了我一条消息 1924（“C-style cast -- More Effective C++ #2”）。

FT_BITS_8 是在第三方头文件中#定义的，演员表在哪里：

#define FT_BITS_8           (UCHAR) 8

而 UCHAR 是来自另一个第三方头文件的 typedef：

typedef unsigned char UCHAR;

它被分配给 (ftDCB.ByteSize) 的东西是一个 BYTE，它也是一个无符号字符的 typedef：

typedef unsigned char       BYTE;

我真的不想修改第三方标头，所以我试图在我的代码中隐藏消息：

//lint -e(1924) C-style cast
ftDCB.ByteSize = FT_BITS_8;

但我收到了同样的 1924 消息。

我在这里做错了什么？有没有更简洁的方法来做我想要完成的事情（除了修改第三方标头）？

【问题讨论】：

reinterpret_cast 呢？
我不想修改第三方头文件，这是实际演员表的来源。
如果 lint 警告来自第三方标头，并且您不想修改该第三方标头，那么您只需要接受警告即可。
你确定这是真的吗，艾米特？我对来自其他第三方库的其他此类警告使用了我认为相同的策略。
那个宏定义甚至都不正确；它应该是#define FT_BITS_8 ((UCHAR) 8)。评估sizeof FT_BITS_8 应该产生1；对于现有定义，sizeof FT_BITS_8 是语法错误。在大多数情况下，这无关紧要，但这是草率的编码。

标签： c++ lint pc-lint

【解决方案1】：

好的，回答我自己的问题，以下似乎可行：

ftDCB.ByteSize = /*lint -e(1924) C-style cast */ FT_BITS_8;

【讨论】：

【解决方案2】：

由于 FT_BITS_8 是一个宏，因此您的 std.lnt 文件中的 -esym(1924,FT_BITS_8) 也会删除此问题的所有实例。

【讨论】：

【解决方案3】：

我刚刚遇到了同样的问题，我找到了一个更好的方法来解决这个问题（请记住，代码可读性是代码质量的一个主要方面，如果它被 lint cmets 乱扔，那就太难看了）。

因此，如果为您提供了一个无法更改的标头（例如微控制器中的外围设备定义），您应该以某种方式包含它们，以便 PC-lint 知道它是一个库标头。有几种方法，最简单的可能是使用尖括号。

所以而不是：

#include "peripheral.h"

用途：

#include <peripheral.h>

这将告诉 PC-lint 将该文件视为库头，这使您可以使用 -elib 和它的兄弟来更好地控制消息。

如果您的消息基于宏，-elibmacro 提供了很好的可能性：

//lint -save
//lint -elibmacro(1924)
#include <peripheral.h>
//lint +elibmacro(1924)
//lint -restore

这将阻止来自peripheral.h 中定义的所有宏的消息 1924，并包含其中。

-save 和 -restore 可能是多余的，但这是我的一个习惯，因为我经常遇到麻烦，一次禁用太多并且不再收到任何消息。

请注意，peripheral.h 中包含的所有标头现在都将被视为库标头，但您通常希望这样做。

您可能需要阅读有关库的 PC-lint 手册第 6 章。

【讨论】：