Re: On PATH_MAX

[Marcus Brinkmann]

At Thu, 3 Nov 2005 11:21:17 -0700,
"Christopher Nelson" <address@hidden> wrote:
> Sure, but in practice how does this work?

In practice it works by first defining what your system looks like,
and then finding out what the constraints are.

The problems you describe stem from the fact that you have a service
that is used by multiple users concurrently, and which expends some of
its own resources in handling those messages.

Under this constraints, you are already violating a number of good
principles.  But let's say that you figure out this is ok in this
circumstance.  Then the least you must do is to ensure that all
requests the service processes have a fixed upper bound, preferably a
really, really small one.

> > To say that the one or the other is stupid is just plain wrong.
> > 
> > Sometimes you should support dynamic reallocation.  Sometimes 
> > you should have a fixed buffer and truncate.  You should not 
> > limit your toolset because of some half-cooked and 
> > (generally) _wrong_ programming dogmas.
> 
> I think it is wrong to have an arbitrary global limit, but I don't
> think that an application imposing an arbitrary *reasonable* limit
> is wrong.  Because we *can* do something is not a good argument for
> actually doing that something.

If all you are saying that a system-wide limit is wrong, then think
again: A system-wide limit is impossible to enforce.  It is totally
possible for you to set up your own filesystem server, expending your
own resources, in which arbitrary long filenames are mapped
transparently to the short "system-wide" limit.  Nothing can stop you
from doing so.  So the whole notion of "global limit" is complete and
utter non-sense.

However, _if_ there is a shared service in your system, then for all I
know the only sane implementations possible will be one that imposes
strict limits on the argument sizes it supports.

You want to use another party's resources, you play by their rules.

Thanks,
Marcus