您使用 TR 24731 的“安全"功能吗? [英] Do you use the TR 24731 'safe' functions?

问题描述

ISO C 委员会 (ISO/IEC JTC1/SC21/WG14) 已发布 TR 24731-1 并且是致力于TR 24731-2:><块引用>

TR 24731-1:C 库的扩展第 I 部分:边界检查接口

WG14 正在研究更安全的 C 库函数的 TR.此 TR 面向修改现有程序，通常通过添加带有缓冲区长度的额外参数.最新草案在文件 N1225 中.理由在文件 N1173 中.这将成为技术报告类型 2.

TR 24731-2:C 库的扩展 - 第二部分:动态分配函数

WG14 正在研究更安全的 C 库函数的 TR.此 TR 面向使用动态分配而不是缓冲区长度的额外参数的新程序.最新草案在文件 N1337 中.这将成为技术报告类型 2.

问题

• 您是否使用支持 TR24731-1 函数的库或编译器?
• 如果是，哪个编译器或库以及在哪个平台上?
• 在修复代码以使用这些函数的过程中，您是否发现了任何错误?
• 哪些功能最有价值?
• 是否有提供无价值或负值的产品?
• 您打算在未来使用图书馆吗?
• 您是否在跟踪 TR24731-2 的工作?

解决方案

自从这些 TR 出现(当时它还是一个单一的 TR)以来，我一直是他们的直言不讳的批评者，并且永远不会在我的任何软件中使用它们.它们掩盖了症状而不是解决原因，我认为，如果有的话，它们将对软件设计产生负面影响，因为它们提供了一种错误的安全感，而不是促进可以更有效地实现相同目标的现有实践.我并不孤单，事实上我不知道在制定这些 TRs 的委员会之外还有一个主要的支持者.

我使用 glibc，因此我知道我将不必处理这些废话，作为 glibc 的主要维护者 Ulrich Drepper，说到这个话题:

<块引用>

建议的 safe(r) ISO C 库未能完全解决问题.... 提议使一个人的生活程序员再难也不会帮助.但这正是建议的....他们都需要更多有待完成的工作或只是简单的工作傻逼.

他继续详细说明了一些提议函数的问题，并在其他地方表示 glibc 永远不会支持这一点.

奥斯汀小组(负责维护 POSIX)对 TR、他们的评论和委员会的回应提供了非常严格的审查 此处.Austin Group 的评论做得非常好，详细说明了 TR 的许多问题，因此我不会在此详细介绍.

所以最重要的是:我不使用支持或将支持此功能的实现，我不打算使用这些功能，并且我在 TR 中看不到任何积极的价值.我个人认为，TR 仍然以任何形式存在的唯一原因是因为微软正在大力推动它，微软最近证明了尽管遭到广泛反对，但它仍然有能力通过标准委员会来解决问题.如果这些功能被标准化，我认为它们不会被广泛使用，因为该提案已经存在了几年并且未能获得任何真正的社区支持.

The ISO C committee (ISO/IEC JTC1/SC21/WG14) has published TR 24731-1 and is working on TR 24731-2:

TR 24731-1: Extensions to the C Library Part I: Bounds-checking interfaces

WG14 is working on a TR on safer C library functions. This TR is oriented towards modifying existing programs, often by adding an extra parameter with the buffer length. The latest draft is in document N1225. A rationale is in document N1173. This is to become a Technical Report type 2.

TR 24731-2: Extensions to the C Library - Part II: Dynamic allocation functions

WG14 is working on a TR on safer C library functions. This TR is oriented towards new programs using dynamic allocation instead of an extra parameter for the buffer length. The latest draft is in document N1337. This is to become a Technical Report type 2.

Questions

• Do you use a library or compiler with support for the TR24731-1 functions?
• If so, which compiler or library and on which platform(s)?
• Did you uncover any bugs as a result of fixing your code to use these functions?
• Which functions provide the most value?
• Are there any that provide no value or negative value?
• Are you planning to use the library in the future?
• Are you tracking the TR24731-2 work at all?

解决方案

I have been a vocal critic of these TRs since their inception (when it was a single TR) and would never use them in any of my software. They mask symptoms instead of addressing causes and it is my opinion that if anything they will have a negative impact on software design as they provide a false sense of security instead of promoting existing practices that can accomplish the same goals much more effectively. I am not alone, in fact I am not aware of a single major proponent outside of the committee developing these TRs.

I use glibc and as such know that I will be spared having to deal with this nonsense, as Ulrich Drepper, lead maintainer for glibc, said about the topic:

The proposed safe(r) ISO C library fails to address to issue completely. ... Proposing to make the life of a programmer even harder is not going to help. But this is exactly what is proposed. ... They all require more work to be done or are just plain silly.

He goes on to detail problems with a number of the proposed functions and has elsewhere indicated that glibc would never support this.

The Austin Group (responsible for maintaining POSIX) provided a very critical review of the TR, their comments and the committee responses available here. The Austin Group review does a very good job detailing many of the problems with the TR so I won't go into individual details here.

So the bottom line is: I don't use an implementation that supports or will support this, I don't plan on ever using these functions, and I see no positive value in the TR. I personally believe that the only reason the TR is still alive in any form is because it is being pushed hard by Microsoft who has recently proved very capable of getting things rammed though standards committees despite wide-spread opposition. If these functions are ever standardized I don't think they will ever become widely used as the proposal has been around for a few years now and has failed to garner any real community support.

这篇关于您使用 TR 24731 的“安全"功能吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！