有人有使用 pc-lint 的好技巧吗?

发布于 2024-08-28 01:47:19 字数 69 浏览 12 评论 0原文

使用 pc-lint 的最佳实践有哪些 - 如何涉足无数选项?

我对读取/解析输出文件的更好方法特别感兴趣。

What are some best practices for using pc-lint - how to wade thru the zillion options?

I'm particularly interested in better ways to read/parse the output files.

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

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

发布评论

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

评论(4

不气馁 2024-09-04 01:47:19

有一个基于 PC-Lint 构建的 Visual Lint,使消息更加友好。不幸的是,它不是免费的,只能在带有 Visual Studio 的 Windows 上运行。他们有试用版 IIRC。

看看

因为我当时的雇主是个小气鬼,所以我没有获取完整版本,尽管我确实发现它很有用。

There's a Visual Lint that builds upon PC-Lint making the messages a bit more friendly. Unfortunately its not free and only works on Windows with Visual Studio. They have a trial version IIRC.

See

Since my employer at the time was a cheapskate I didn't get the full version, although I did find it useful.

寒冷纷飞旳雪 2024-09-04 01:47:19

ALOA 项目 提供免费代码来解析 PC-Lint 输出并在重复运行时运行回归分析。

我推荐了一篇不错的小文章 如何使用 PC Lint

发布 Visual Lint 的 Riverblade 人员发表了几篇有关配置的文章:

The ALOA project offers free code to parse PC-Lint output and run regression analysis on repeated runs.

There's a nice little article How to wield PC Lint that I recommend.

The Riverblade people who publish Visual Lint published a couple of articles on config:

满身野味 2024-09-04 01:47:19

好吧,我不知道有哪些免费/开源工具旨在处理 pc-lint 输出,但我使用了以下策略,使用 splint

  1. 来决定打开哪些选项:我们查看了我们所拥有的缺陷,并了解了哪些缺陷可能会产生被夹板检测到。实际上,这是一个检查夹板选项并决定天气的问题,如果不加以检测,就会给我们带来问题。
  2. 关于处理输出,我们开发了一些 awk 脚本,它们会给出警告摘要,并详细说明其中的情况每个警告都会发生,而不是与编译器输出交织在一起。还有一个选项只报告新/修改代码的警告。

Well I don't know of free/opensource tools designed to process pc-lint output, but I have used the following strategy using splint

  1. To decide on which options to turn on: We looked at the defects we have had and seen which could have been detected by splint. Really it was a matter of going through the splint options and deciding weather it is something that if left undedected has or will cause a problem for us
  2. Regarding process the output, we developed some awk scripts that would give a summary of warning, and details where each warning occurred instead of having it intertwined with the compiler output. There was also an option to only report warnings on new/modifed code.
雨夜星沙 2024-09-04 01:47:19

“Indian Hill C 风格和编码标准” 讨论了使用 Lint 的方法。

我对任何静态分析工具的方法都是定义本地编码标准(或使用现有的编码标准),然后应用强制执行该标准的静态分析规则。明确关闭您允许的代码规则,并保留您的标准从未考虑过的所有方面的规则;当它们发生时,请考虑您的编码标准是否需要修改,或者是否应该关闭规则,或者这是否只是一个编码错误,应该在不更改标准或分析仪配置的情况下修复。

The "Indian Hill C Style and Coding Standards" talks about approaches to using Lint.

My approach to any static analysis tool is to define your local coding standard (or use an existing one), then apply the static analysis rules that enforce that standard. Explicitly switch off the rules for code that you allow, and leave on the rules for all those aspects your standard never even considered; when they occur, consider whether your coding standard needs modification or if the rule should be switched off, or whether it was simply a coding error that should be fixed without change to either the standard or the analyser configuration.

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