在 Ubuntu 10.04 上编译时未声明 PATH_MAX
我正在尝试在 Ubuntu 10.04 中为 8.04 编译一个 C 程序。它失败是因为我们使用了 PATH_MAX 和其他应在 limits.h 中定义的常量。根据各种资源，它应该是 POSIX 兼容 C 库的一部分。
这是 Ubuntu 10.04 中的错误还是有解决此问题的正确方法？
I am trying to compile a C program in Ubuntu 10.04 made for 8.04. It fails because we have used PATH_MAX and other constants that should be defined in limits.h. According to various resources, it should be part of a POSIX compatible C library.
Is this a bug in Ubuntu 10.04 or is there a proper way of solving this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
POSIX 定义了许多这样的限制是可选的。如果
limits.h中未定义限制 FOO，则意味着系统可能没有此类限制，或者该限制可能会在运行时发生变化，或者取决于其所应用的路径名。在这些情况下，您可以使用pathconf、fpathconf或sysconf函数以及_PC_*和_SC_*宏，如：或：
不幸的是，GNU（GNU C 库）将许多限制定义为运行时变量，而实际上它们在 Linux 上是恒定的，在某些人（在我看来，非常误导）希望有一天限制将被取消，应用程序将立即能够利用限制的取消。然而，对于应用程序和内核的鲁棒性来说，只要它们足够大（如 Linux 限制），设置固定限制实际上会更好。
POSIX defines many such limits to be optional. If a limit FOO is not defined in
limits.h, it means the system may have no such limit or the limit might vary at runtime or dependent upon the pathname it's applied to. In these cases, you use thepathconf,fpathconf, orsysconffunctions and the_PC_*and_SC_*macros, as in:or:
Unfortunately GNU (the GNU C library) defines many limits as runtime-variable when they're actually constant on Linux, in some (in my opinion, very misguided) hope that someday the limits will be removed and applications will immediately be able to take advantage of the removal of the limits. However, for application and kernel robustness, it's actually much better to have fixed limits as long as they're sufficiently large (as the Linux limits are).