[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[address@hidden: Re: serious bug. Evolution and Microsoft mentality.]
From: |
Adam Olsen |
Subject: |
[address@hidden: Re: serious bug. Evolution and Microsoft mentality.] |
Date: |
Fri, 11 Jan 2002 03:20:20 +0000 |
User-agent: |
Mutt/1.3.25i |
Jeff: I decided it's easier to forward this to a proper hurd list,
rather than relaying info for things I can't check myself :)
The basic question is whether realpath() uses _POSIX_PATH_MAX as the
limit, which is a useful behavior (atleast as far as realpath goes),
or whether it uses no limit at all, which is as useless as gets().
As for portability, I think the best is to use canonicalize_file_name
when it's available, and fallback to realpath if it's not. Otherwise,
although your program would compile, it'd be broken if you ever got a
path that was too long (either by crashing or getting the file wrong).
And don't say it won't happen. The hurd is *alot* more flexible than
traditional systems, so it's more than possible somebody could dream
up a use for it in the future.
----- Forwarded message from Jeffrey Stedfast <fejj@ximian.com> -----
Subject: Re: serious bug. Evolution and Microsoft mentality.
From: Jeffrey Stedfast <fejj@ximian.com>
To: Adam Olsen <rhamph@d2dc.net>
Organization: Ximian, Inc.
Er wait, if both PATH_MAX and _POSIX_PATH_MAX are defined, then PATH_MAX
>= _POSIX_PATH_MAX - right... *however*, if PATH_MAX isn't defined, then
_PATH_MAX can be assumed to be == _POSIX_PATH_MAX, thus no overflows :-)
personally I don't like buffers with size limits, but I can't use
canonicalize_file_name() because the function isn't portable (ie it's a
glibc-ism and thus I'd still have to use the current code when porting
to HPUX, AIX, Solaris, etc and so doesn't gain me anything except
untested code ;-)
Jeff
On Thu, 2002-01-10 at 21:05, Adam Olsen wrote:
> On Thu, Jan 10, 2002 at 09:03:21PM -0500, Jeffrey Stedfast wrote:
> > I've now fixed it so that if PATH_MAX isn't defined, it instead uses
> > _POSIX_PATH_MAX which is the minimum path length. The only way for
> > PATH_MAX to be left undefined (according to the POSIX specification) is
> > if PATH_MAX would be equal to _POSIX_PATH_MAX.
>
> Ahh, but that's the minimum, not the maximum. And afaik realpath uses
> the maximum. Still overflows.
>
> >
> > Jeff
> >
> > On Thu, 2002-01-10 at 19:19, Adam Olsen wrote:
> > > On Thu, Jan 10, 2002 at 06:59:40PM -0500, Jeffrey Stedfast wrote:
> > > > Interestingly enough, PATH_MAX is defined in the POSIX.1 specification.
> > > >
> > > > This suggests to me that the HURD is broken.
> > >
> > > [00:17:08] <marcus> Rhamp, PATH_MAX is optional
> > > [00:17:21] <marcus> Rhamp, it is allowed to be defined, but not required.
> > >
> > >
> > > >
> > > > On Thu, 2002-01-10 at 18:38, Adam Olsen wrote:
> > > > > On Thu, Jan 10, 2002 at 06:41:35PM -0500, Jeffrey Stedfast wrote:
> > > > > > we'll deal with this after you port the rest of evolution's
> > > > > > dependencies
> > > > > > to the HURD.
> > > > >
> > > > > Why not do it now and save the trouble later?
> > > >
> > > > instead of bugging me about porting to a broken platform, why don't you
> > > > do it?
> > >
> > > I don't use Evolution. I just thought I was doing you a favour by
> > > informing you of the problem.
> > >
> > > --
> > > Adam Olsen, aka Rhamphoryncus
> > --
> > Jeffrey Stedfast
> > Evolution Hacker - Ximian, Inc.
> > fejj@ximian.com - www.ximian.com
> >
> >
>
> --
> Adam Olsen, aka Rhamphoryncus
--
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj@ximian.com - www.ximian.com
----- End forwarded message -----
--
Adam Olsen, aka Rhamphoryncus
- [address@hidden: Re: serious bug. Evolution and Microsoft mentality.],
Adam Olsen <=