其中的函数在C标准库通常鼓励不好的做法？ [英] Which functions in the C standard library commonly encourage bad practice?

问题描述

这是由这个问题并在在一个特定的答案的评论我了解到，函数strncpy 不是一个很安全的字符串用C处理函数，它垫零，直到它到达 N ，这是我不知道的。

This is inspired by this question and the comments on one particular answer in that I learnt that strncpy is not a very safe string handling function in C and that it pads zeros, until it reaches n, something I was unaware of.

具体来说，引用 - [R ..

函数strncpy不空终止，并
  不空垫的整个剩余
  目标缓冲区，这是一个
  时间的巨大浪费。你可以工作
  绕前，加入自己的
  空填充，而不是后者。它
  从来没有打算用作安全
  字符串处理功能，但对于
  在Unix的固定大小的领域工作
  目录表和数据库文件。
  的snprintf（DEST，N，％S，SRC）是
  唯一正确的安全strcpy的标准
  C，但它可能会慢很多。
  顺便说一下，截断本身可以
  是一个重大错误，在某些情况下可能
  导致权限提升或DOS，所以
  抛出安全的字符串函数
  截断它们的输出在问题
  没有办法让它安全或
  安全。相反，你应该确保
  该目标缓冲区是
  正确的尺寸和简单地使用的strcpy（或
  更好的是，memcpy的，如果你已经知道
  源字符串的长度）。

strncpy does not null-terminate, and does null-pad the whole remainder of the destination buffer, which is a huge waste of time. You can work around the former by adding your own null padding, but not the latter. It was never intended for use as a "safe string handling" function, but for working with fixed-size fields in Unix directory tables and database files. snprintf(dest, n, "%s", src) is the only correct "safe strcpy" in standard C, but it's likely to be a lot slower. By the way, truncation in itself can be a major bug and in some cases might lead to privilege elevation or DoS, so throwing "safe" string functions that truncate their output at a problem is not a way to make it "safe" or "secure". Instead, you should ensure that the destination buffer is the right size and simply use strcpy (or better yet, memcpy if you already know the source string length).

和来自乔纳森·莱弗勒

注意strncat函数（）更是
  在它的界面比混乱
  函数strncpy（） - 究竟是
  长度参数，再？它不是什么
  你所期望的基础上所提供内容
  函数strncpy（）等 - 因此它是更多的错误
  俯卧甚至比函数strncpy（）。对于复制
  周围的字符串，我越来越多的
  认为有较强
  说法，你只需要的memmove（）
  因为你总是知道所有的大小
  提前并确保有
  提前足够的空间。使用
  memmove与（）在preference任何的
  的strcpy（），strcat的（），函数strncpy（），
  strncat函数（）的memcpy（）。

Note that strncat() is even more confusing in its interface than strncpy() - what exactly is that length argument, again? It isn't what you'd expect based on what you supply strncpy() etc - so it is more error prone even than strncpy(). For copying strings around, I'm increasingly of the opinion that there is a strong argument that you only need memmove() because you always know all the sizes ahead of time and make sure there's enough space ahead of time. Use memmove() in preference to any of strcpy(), strcat(), strncpy(), strncat(), memcpy().

所以，我显然对C标准库有点生疏。因此，我想提出一个问题：

So, I'm clearly a little rusty on the C standard library. Therefore, I'd like to pose the question:

什么C标准库函数使用不当/在可能导致/导致安全问题的方法/ code缺陷/低效？

在客观性的利益，我有一个答案了一些标准：

In the interests of objectivity, I have a number of criteria for an answer:

• 请，如果可以的话，举问题，即其预期目的的功能设计背后的原因。


• 请突出显示该code目前正在把误操作。


• 请说明为什么滥用可能对有问题导致。我知道这应该是显而易见的，但它prevents软答案。

请避免：

• 在辩论中的命名约定的功能（除非该unequivocably造成混乱）。


• 我preFER点¯x在Y - preference是确定的，我们每个人都有他们，但我感兴趣的是实际的意外的副作用，以及如何防范它们

由于这是可能被认为是主观的，也没有明确的答案，我标记为社区维基立竿见影。

As this is likely to be considered subjective and has no definite answer I'm flagging for community wiki straight away.

我也工作作为每C99。

I am also working as per C99.

推荐答案

有一个常见的​​错误的的strtok（）函数是假设分析的字符串保持不变，而它实际上替换的分隔符'\\ 0'。

A common pitfall with the strtok() function is to assume that the parsed string is left unchanged, while it actually replaces the separator character with '\0'.

此外，的strtok（）是通过它的后续调用，直到整个字符串标记化使用。一些库实现存储的strtok（）的一个全局变量内部状态，这可能会导致一些讨厌的suprises，如果的strtok（）从多个线程同时调用

Also, strtok() is used by making subsequent calls to it, until the entire string is tokenized. Some library implementations store strtok()'s internal status in a global variable, which may induce some nasty suprises, if strtok() is called from multiple threads at the same time.

借助 CERT C安全编码标准列出了许多这些缺陷你问一下。的

The CERT C Secure Coding Standard lists many of these pitfalls you asked about.

这篇关于其中的函数在C标准库通常鼓励不好的做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！