X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
Date: Sun, 09 Aug 2009 21:00:09 +0300
From: Eli Zaretskii <eliz AT gnu DOT org>
Subject: Re: fopen/open and pathnames with trailing slash
In-reply-to: <200908091551.19052.juan.guerrero@gmx.de>
X-012-Sender: halo1 AT inter DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-id: <83k51clvfa.fsf@gnu.org>
References: <200908091551 DOT 19052 DOT juan DOT guerrero AT gmx DOT de>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> Date: Sun, 9 Aug 2009 15:51:18 +0200
> 
> While I was trying to port m4 I have noticed that the configure script complains
> that both functions fopen() and open() do not handle correctly the case when the
> pathnames end with a slash.

Does that do any harm?  Or does M4 include work-arounds for such
systems?

> 1) According to POSIX: If the filename contains at least one non-slash character
>    and ends with one or more trailing slashes and one of the modes O_CREAT,
>    O_WRONLY or O_RDWR is specified, then open() must fail with EISDIR.
>    The same applies for fopen() if the modes w or a have been specified.
> 2) According to POSIX: If the filename ends in a slash and the file descriptor
>    of the named file without the slash does not refer to a directory, then open()
>    must fail with ENOTDIR.
> See:  <http://www.opengroup.org/susv3/basedefs/xbd_chap04.html>,
>       <http://www.opengroup.org/susv3/functions/fopen.html> and
>       <http://www.opengroup.org/susv3/functions/open.html>

I think this is a version of Posix standard to which DJGPP doesn't
conform, anyway.

> Because open() is also called by fopen() to do the job, the issue needs only to
> be fixed there.

Do we really need to fix it?  It sounds like a potential to break
existing programs is high, while the benefits are vague at best.

> +  if (((oflag & (O_RDONLY | O_CREAT | O_WRONLY | O_RDWR)) != O_RDONLY) && \
> +      !is_root_dir && IS_SLASH(filename[length - 1]))

If we do accept this change of behavior, I think it's definitely wrong
to support it when the last character is a backslash.  Posix file
names should end with a forward slash, so I don't think we should
support Posix rules for non-Posix file names.