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