help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: weird PATH_MAX discussion in mplayer's list. (Fwd: [MPlayer-dev-eng]


From: mike burrell
Subject: Re: weird PATH_MAX discussion in mplayer's list. (Fwd: [MPlayer-dev-eng] [PATCH] fix for unconditional use of PATH_MAX)
Date: Thu, 1 May 2003 12:23:32 -0600
User-agent: Mutt/1.4i

Robert Millan (zeratul2@wanadoo.es) said:
> please someone could lend me a hand? i'm having trouble with these
> people trying to convince them to support systems without PATH_MAX
> 
> they keep insisting on hardcoding PATH_MAX to 512 bytes.. with
> this last message (see below) it's getting realy weird. if someone can
> help please read the archived discussion:
> 
>   http://mplayerhq.hu/pipermail/mplayer-dev-eng/2003-April/018199.html

First of all, your patch is not good.  It invokes undefined behaviour on
every platform without PATH_MAX that is not GNU.  Not good if you want to
promote portability, methinks.

In any case, arbitrary limits should probably be avoided for no other reason
than the GNU coding guide says not to do it :)

This is not an isolated problem with mplayer, though.  My recommendation
would be to look at common idioms such as:
        char path[PATH_MAX + 2];
        getcwd(path, PATH_MAX);
and try to come up with a function/macro that is general enough to be dropped
in anywhere: replace one bad habit with another, I guess ;)

e.g. (just off the top of my head):

#ifndef _GNU_SOURCE
/*
 * if _GNU_SOURCE is defined, then get_current_dir_name is already in scope
 *
 */
#ifdef PATH_MAX
char *
get_current_dir_name(void)
{
        char *p = malloc(PATH_MAX);
        
        if (! p)        return 0;
        return getcwd(p, PATH_MAX);
}
#else   /* no PATH_MAX and not GNU (what is it?) */
char *
get_current_dir_name(void)
{
        int l = 64;
        char *p = malloc(l);
        
        if (! p)        return 0;

        /* taking advantage of getcwd() ONLY failing on ERANGE */
        while (! getcwd(p, l)) {
                char *p_;
        
                l *= 2;
                p_ = realloc(p, l);
                if (! p_) {
                        free(p);
                        return 0;
                }
                p = p_;
        }
        
        return p;
}
#endif

and then encourage people to use get_current_dir_name() instead of getcwd()
always.  If you have a well-used robust piece of code (which I'm not
pretending this is), then you'll clamp down on a whole bunch of bugs in all
sorts of software.  Of course the other change to the idiom above is that
people have to free() it afterwards too :\

Anyway, that's my thought on the matter.  Instead of going after all the
PATH_MAX offenders separately, try to find an easy replacement that no one
could possibly think a bad idea :)

> On Thu, May 01, 2003 at 10:15:54AM -0400, D Richard Felker III wrote:
> > 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.....

This is a nonsense argument, of course.  If an OS is susceptible to such
denials of service, then it provides a PATH_MAX to compensate.  Therefore,
any system without a PATH_MAX must be suspectible?  No.  On well-designed
systems, a 500MB pathname should cause no overhead on a syscall (whether the
Hurd does this is another question).

-- 
 /"\                                                 m i k e   b u r r e l l
 \ /     ASCII RIBBON CAMPAIGN                                mikpos@shaw.ca
  X        AGAINST HTML MAIL,
 / \      AND NEWS TOO, dammit




reply via email to

[Prev in Thread] Current Thread [Next in Thread]