I appreciate the intent of your suggestion, but I don't think it can
actually meet its goals.
I don't think that defining PATH_MAX invalidly will actually be a net gain
at all. If defined, PATH_MAX must be a constant. If you have a plan and
you cannot compile:
static char name[PATH_MAX];
under your plan, then I don't think it's a plan that will help reduce
problems or confusion; rather it will in fact worsen the situation for
miscellaneous maintainers and for Hurd folks' interactions with them.
There is no possible plan that works for that but does not violate the
basic truth of dynamic size that leaving PATH_MAX undefined expresses.
> What might be a problem is code that currently does a ``ifndef PATH_MAX''
> to catch `PATH_MAX' not being defined and branches to some dynamic
> allocation in that case. But is that really a valid show-stopper? If
> dynamic allocation is possible (and already implemented!) why not use it
> unconditionally then?
On a system where PATH_MAX is defined, it is entirely reasonable and
appropriate to use it as a compile-time constant. There is no reason to
build in the complexity of dynamic allocation when it is never useful.
On a system where the true limit is unavoidably statically constrained
(e.g. by the kernel as is the case on traditional Unixoid systems), it is
pretty hard to make a case for dynamic allocation. I think it will be a
much harder sell to upstream maintainers than the conditionalized
portability that is what's necessary for POSIX conformance and Hurd
compatibility.
Thanks,
Roland
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-hurd
