Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > The dirname() tests file were developed and tested on only the five > platforms available to the developer at the time, namely: Linux (both 32 > and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit. > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html > (i.e. the POSIX spec) says, in part: > > 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. > > The thinking behind testing precise, OS-dependent output values was to > document that different setups produce different values. However, as the > test failures on MacOSX illustrated eloquently: hardcoding pretty much each > and every setup's expectations is pretty fragile. > > This is not limited to the "//" vs "/" case, of course, other inputs are > also allowed to produce multiple outpus by the POSIX specs. > > So let's just test for all allowed values and be done with it. This still > documents that Git cannot rely on one particular output value in those > cases, so the intention of the original tests is still met. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- Sounds sensible. Thanks. This is not a problem with this patch, but the resulting basename_data[] array seems to test "C:/usr" going to "usr" twice under _MSC_VER or __MINGW32__. Also... > -#if defined(__MINGW32__) > - /* the following is clearly wrong ... */ > - { "C:", "." }, > -#endif > - > -#if defined(_MSC_VER) > - { "C:", "C:." }, > -#endif > - > -#endif > + { "C:", "C:.", "." }, > #endif "C:" is still allowed to go to "."; is it still "clearly wrong", or do we have a reason why we think it is not wrong at all? I think the comment was written by Ramsay and also suspect that you did not specifically agree or disagree with that particular decision, so I'd understand if you do not have a strong opinion either way, but I'd like to hear from Ramsay. Perhaps earlier we thought it was clearly wrong but we no longer do? -- 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