php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #7873 Dirname inconsistency
Submitted: 2000-11-18 11:39 UTC Modified: 2000-11-19 10:13 UTC
From: trifid at redigy dot cz Assigned:
Status: Closed Package: *Function Specific
PHP Version: 4.0.3pl1 OS: Linux 2.2.16/glibc 2.1
Private report: No CVE-ID: None
 [2000-11-18 11:39 UTC] trifid at redigy dot cz
The last change in ext/standard/string.c brought very bad inconsistency into 
dirname behaviour:

echo dirname("/foo/bar/")."/foobar";     =>    /foo/foobar
echo dirname("/foo/")."/foobar";         =>    //foobar

the function should everytime return a path with or without a slash at the end, 
but always the same.

I created a very simple patch that will stop returning a slash at the end in any
case:

--- string.c.orig       Sat Nov 18 17:00:28 2000
+++ string.c    Sat Nov 18 17:04:53 2000
@@ -714,8 +714,7 @@
        }
        if (end < path) {
                /* The path only contained slashes */
-               path[0] = DEFAULT_SLASH;
-               path[1] = '\0';
+               path[0] = '\0';
                return;
        }
 
@@ -735,8 +734,7 @@
                end--;
        }
        if (end < path) {
-               path[0] = DEFAULT_SLASH;
-               path[1] = '\0';
+               path[0] = '\0';
                return;
        }
        *(end+1) = '\0';

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-11-19 09:06 UTC] stas@php.net
This is the same way as "pwd" function behaves, so I guess
your loginc od always adding / is not correct. Or you have
to live with // on the root path. This is because root path
is different from other pathes - / is actually its name,
while on other pathes / is just a delimiter. Your patch
makes root path to be "", which is obviously wrong.

 [2000-11-19 10:13 UTC] trifid at redigy dot cz
But PHP's dirname() used to work 'my' way allways, and I've seen a _lot_ of code that
is broken by its current behaviour - a '//' on root is good for filesystem, but imagine
a package which uses dirname($SCRIPT_NAME) to determine its web addres
<a href=<? echo dirname($SCRIPT_NAME); ?>/foobar.html>
produces in current version
<a href=//foobar.html> 
which is obviously an invalid link.
There is nothing wrong with 'pwd' as long as a filesystem understands something
like '//'... but a web browser don't, and that's why I thought the original dirname()
behaviour was intentional and very good.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 14:01:32 2024 UTC