在直接C中编写安全代码时，我已经厌倦了想出任意的事情 代表限制的数字 - 具体来说，是最大数量 要为单行文本分配的内存。我知道我总能说 像
这样的东西#define MAX_LINE_LENGTH 1024
然后将该宏传递给snprintf（）等函数。
我在NetBSD中工作和编码，它有一个名为sysctl（3）的变量 为此目的而设计的“user.line_max”。所以我不需要上来 使用任意数字，如上面的MAX_LINE_LENGTH。我刚看完了 “user.line_max”sysctl变量，顺便可以由用户设置。
我的问题是这在安全性方面是否是正确的事情 可移植性。也许不同的操作系统有不同的名称 这个sysctl，但我更感兴趣的是我是否应该使用它 技术。
对于记录，“可移植性”在这种情况下排除了Microsoft Windows。
答案 0 :(得分：1)
linux SYSCTL（2）手册页在Notes部分有这个说法：
Glibc不为此系统调用提供包装器;使用系统调用（2）调用它。 或者更确切地说......不要调用它：长期以来一直不鼓励使用这个系统调用，并且它很可能在未来的内核版本中消失。立即将其从您的程序中删除;改为使用/ proc / sys接口。
所以这是一个考虑因素。
答案 1 :(得分：1)
不是个好主意。即使它不是Duck告诉你的，依赖于系统范围的设置，运行时变量是糟糕的设计和容易出错。如果您要解决缓冲区大小限制可变（通常需要动态分配和检查失败）的问题，那么您应该进行最后一步并使其可以在更局部的范围内进行配置。
以缓冲区大小限制为例，对最佳做法的看法不同。有些人认为你应该总是使用没有硬限制的动态增长缓冲区。其他人更喜欢足够大的固定限制，以至于合理的数据不会超过它或者，正如您所指出的，可配置限制是一种选择。在选择适合您应用程序的内容时，我会考虑用户体验的含义。当然用户不喜欢任意限制，但是当他们意外地（或被其他人的恶意）读取没有换行符的数据时他们也不喜欢它会导致你的应用程序消耗无限量的内存，开始交换和/或最终崩溃或陷入整个系统。
答案 2 :(得分：1)
最近的便携式构造是“getconf LINE_MAX”或等效的C。
答案 3 :(得分：0)
1）查看Single Unix Specification，关键字：“limits”
2）s / safety / security /