Thread (8 messages) flat view 8 messages, 4 authors, 2016-06-15

Re: [PATCH] t0060: loosen overly strict expectations

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:07:45

Johannes Schindelin [off-list ref] 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 <redacted>
---
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help