[Top][All Lists]

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

Re: {base,dir}name // semantics

From: Eric Blake
Subject: Re: {base,dir}name // semantics
Date: Fri, 04 Nov 2005 20:44:49 -0700
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Hash: SHA1

According to Eric Blake on 7/9/2005 2:49 PM:
>>>should this patch be made globally, or should it be limited to only
>>>systems that have a distinct //, leaving other platforms to continue
>>>having just a single slash returned?
>>Limit it to just those systems, please.
> I take it a simple autoconf test is in order (how about just testing
> to see if 'ls -di / //' produces 2 different inodes?), and that the
> results be used in the gnulib dirname module.
>>>I would argue that cross-platform consistency is more important
>>But that cuts both ways: Solaris "dirname //" outputs "/",
>>and why should GNU/Linux dirname do anything differently?
>>Let's not change this except on the poor platforms where leading // is

In working on preparing my patch for the dirname module, I realized that
there is a slight complication to the plan proposed in this old thread.
Using 'ls -di / //' in autoconf tests the host, not the build platform, so
it is an invalid test for cross-compilation.  For native compiles, it is
easy to tell if // is special and thus control the behavior of
dir_name("//"), but for cross compilation, should I be pessimistic and
make dir_name("//") always return "//" (unless overridden by priming the
cache, of course)?  Or should I write the test with hard-coded knowledge
of the HOST values that are known to have distinct // (so far, I only know
of cygwin), and stick with dir_name("//") returning "/" on all other

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


reply via email to

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