[MPlayer-dev-eng] [PATCH] fix for unconditional use of PATH_MAX

[Robert Millan]

On Thu, May 01, 2003 at 10:15:54AM -0400, D Richard Felker III wrote:
> > if you don't want to stick with two code snippets (one for PATH_MAX and
> > other for non-PATH_MAX), then just use dynamic allocation as someone
> > suggested before. that will work for all systems.
> 
> I agree this is acceptable, but IMO it's not worth the code clutter.
> It's definitely not worth #ifdef clutter.

ok. if using dynamic allocation only is ok to you, then do that
and let's leave it here.

on the other hand, if you want to know about the dessign of
the GNU system core (Glibc/Hurd), read below.

> On Thu, May 01, 2003 at 02:35:01PM +0200, Robert Millan wrote:
> > 
> > please don't do that, it's a _bad_ solution. what if i run mplayer in
> > a directory longer than 512 bytes? then it will fail or not work as
> > expected.
> 
> Then you deserve what you get for making such a nonsense directory!!
> 
> [...]
> 
> > if you hardcode PATH_MAX, you'll recieve bug reports from users telling
> > that mplayer fails or behaves unexpectedly.
> 
> No, no one uses such long paths, because on ALL unices but Hurd,
> they're forbidden!
> 
> [...]
> 
> There's a reason PATH_MAX exists. In order to make an operating system
> robust, there have to be resource limits on users. If I could make a
> 500-meg directory name, then pass it to a syscall, that would be some
> serious denial of service on the system.....

the GNU system core (ie Glibc with the Hurd) is much different to most
Unices you are used to, and the same conventions don't always apply.

there's a reason why PATH_MAX is not defined on GNU. the reason is
that the system dessign permits users to use paths as long as they like
without compromising system's robustness. for example, it might surprise
you that there's no syscall() on the GNU system, because the Glibc
functions that would use them do implement the actual work themselves
instead.

the Hurd is a collection of servers, which includes filesystem servers.
these filesystem servers have no notion about POSIX or any idea on
what a full path means.

this means the filesystem server that serves your, say, /home partition
has no idea on what it's actualy serving. when i want to access
/home/something, the Glibc file calls will ask the root filesystem
for /home/something, and obtain that /home/something belongs to another
filesystem server, so it will then ask the fs server that serves
/home for a file called /something. this works recursively, if i wanted,
i could mount a thousand filesystems one on top of the other and
none of them would care about its respective parent.

in this context, imposing an arbitrary limit like PATH_MAX doesn't make
any sense, because the full path of a file is merely a convention
formed by putting server paths together. if i created a 500MB length path
(assuming i can store it in memory), Glibc would have no trouble to resolve
it and pass it to a system server.

of course, a filesystem server _may have_ a limit on the local path
length it can cope. i don't know if a filesystem server can cope with
500MB length path (never tried), but this has _nothing_ to do with
PATH_MAX, because PATH_MAX refers to the complete path.

if you are realy interested on dessign issues of the GNU system core,
have a look at:

	http://www.gnu.org/software/hurd/docs.html

these ones are specialy interesting:

	http://www.gnu.org/software/hurd/hurd-paper.html
	http://www.gnu.org/software/hurd/hurd-talk.html

-- 
Robert Millan

make: *** No rule to make target `war'.  Stop.

Another world is possible - Just say no to genocide