Re: [PATCH v4 4/4] t0060: verify that basename() and dirname() work as expected

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

 



Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx> writes:

> This particular section documents what is almost certainly a bug
> in the cygwin basename() and also documents my choice of 'fix'.
> (ie. in my implementation I chose to return '/' for '//', which
> is one of the possible options that POSIX allows.)
> ...
> POSIX says, in part [1]:
>
>     If the string pointed to by path consists entirely of the '/' character,
>     basename() shall return a pointer to the string "/". If the string pointed
>     to by path is exactly "//", it is implementation-defined whether '/' or "//"
>     is returned.
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
>
> So we should expect other systems to differ, even if they support POSIX. (and maybe
> not just this test case.)

Doesn't that mean the test shouldn't be insisting on the output
being one that you arbitrarily pick?  It feels to me that it is
wrong to say "We require // to become / unless we know we are on
such and such systems".  Instead, shouldn't it be doing "We feed //
to the function.  Either / or // is acceptable; any other value is a
bug"?

It is tempting to have a "check" feature to the test program for the
curious which one of the two acceptable results a particular platform
(or more precisely, implementation of basename/dirname) produces, but
I do not think "test" feature should insist on / and reject //.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]