This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: [ECOS] Bugs in path handling for JFFS2, RAMFS and ROMFS
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: Andrew Lunn <andrew at lunn dot ch>
- Cc: Vincent Catros <Vincent dot Catros at elios-informatique dot fr>, ecos-patches at ecos dot sourceware dot org
- Date: 21 Feb 2004 14:13:39 +0000
- Subject: Re: [ECOS] Bugs in path handling for JFFS2, RAMFS and ROMFS
- References: <000001c3f7b1$6a93f7a0$7407a8c0@figuier><20040220190221.GC1496@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> On Fri, Feb 20, 2004 at 01:59:46PM +0100, Vincent Catros wrote:
> > Hello,
> >
> > I found 2 bugs in path handling for JFFS2, RAMFS and ROMFS.
> >
> > BUG 1 : Multi '/' path.
> > Description :
> > If you use path with multi '/' that doesn't work.
> > i.e : chdir("/tmp////tmp")
> >
> >
> > BUG 2 : '/' terminated path.
> > If you use path terminated with a '/' that doesn't work.
> > i.e : chdir("/tmp/")
> >
> > Proposed patchs fixe this issues.
>
> I know this is generally accepted with unix like systems, but could
> somebody point me towards a section of the POSIX standard that states
> this?
I think that the POSIX standard is scrupulously careful not to make
any assumptions about filename formats. It is, after all, meant to run
on systems as diverse as IBM mainframes and VAX VMS, where the
filename formats are wildly different from the UNIX pathname. In UNIX
it is not even clear what multiple slashes even mean. In Linux they
are elided, but in other systems they might have other meanings.
In eCos we have adopted the UNIX naming convention, so in theory it is
not unreasonable to make assumptions about filename formats. We do so
in routines like getcwd() for example.
However, most of the time when filenames are used, they are string
constants. When they are constructed at runtime I think it is not
unreasonable to expect this to be done properly. Therefore I am
reluctant to add extra code to eCos just to compensate for what is
effectively lazy application programming. The cost should go where it
belongs, in the application, and not into every eCos program whether
it needs it or not.
I would therefore vote against this patch.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts