Re: [PATCH v2 3/8] absolute_path(): reject the empty string

> On 09/07/2012 01:09 AM, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> 
>>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>>> ---
>> 
>> I think I asked why this matters (iow, why it is the right thing to
>> do to reject an empty string, instead of treating it as "the current
>> directory") in the previous round.  I would have expected to find
>> the answer be above the S-o-b line here.
>
> The reasons that the change is desirable:
>
> 1. The empty string is not a legitimate path according to POSIX; e.g.,
> see Linux's path_resolution(7):
>
>    Empty pathname
>        In the original UNIX, the empty pathname referred to the current
>        directory.   Nowadays  POSIX  decrees  that  an  empty  pathname
>        must not be resolved successfully.  Linux returns ENOENT in this
>        case.
>
> Accordingly, comparable standard functions like realpath(3) reject the
> empty string.
>
> 2. The functions did not handle the empty path consistently with the way
> they handled other paths (namely, the return value contained a trailing
> slash).
>
> 3. This unusual behavior was undocumented.
>
> The above points let me to the conclusion that the anomalous handling of
> the empty string was a bug in the implementation rather than an intended
> behavior.  Moreover, a quick check of callers didn't turn up any that
> seemed to rely on the strange behavior.
>
> Do you want a re-roll with this verbiage added to the commit messages of
> the two relevant commits?