In the most important GNU package, I can see 3 uses of IS_RELATIVE_FILE_NAME:
libvirt/src/qemu/qemu_domain.c
tar/src/misc.c
coreutils/src/basename.c
In the first two, the code assumes that IS_RELATIVE_FILE_NAME(F) means that
you can append F to a directory and get a meaningful file name. But with the
current definition of IS_RELATIVE_FILE_NAME, this is not true:
IS_RELATIVE_FILE_NAME("c:") returns true, but \foo\bar\c: is not a valid file
name.
Let me fix this.
For the third occurrence, the change does not matter.
2020-03-28 Bruno Haible <[email protected]>
dosname: Change IS_RELATIVE_FILE_NAME.
* lib/dosname.h (IS_RELATIVE_FILE_NAME): On native Windows, OS/2, DOS,
change the definition so that IS_RELATIVE_FILE_NAME("c:") is false.
* NEWS: Mention the change.
diff --git a/NEWS b/NEWS
index 3ec49f3..c9548d5 100644
--- a/NEWS
+++ b/NEWS
@@ -58,6 +58,9 @@ User visible incompatible changes
Date Modules Changes
+2020-03-28 dosname On native Windows, OS/2, DOS,
+ IS_RELATIVE_FILE_NAME("c:") now returns false.
+
2020-03-28 filename The macro IS_ABSOLUTE_PATH is deprecated. Use
IS_ABSOLUTE_FILE_NAME instead.
The macro IS_PATH_WITH_DIR is deprecated. Use
diff --git a/lib/dosname.h b/lib/dosname.h
index 5782960..926a695 100644
--- a/lib/dosname.h
+++ b/lib/dosname.h
@@ -47,6 +47,7 @@
# define IS_ABSOLUTE_FILE_NAME(F) \
(ISSLASH ((F)[0]) || FILE_SYSTEM_PREFIX_LEN (F) != 0)
#endif
-#define IS_RELATIVE_FILE_NAME(F) (! IS_ABSOLUTE_FILE_NAME (F))
+#define IS_RELATIVE_FILE_NAME(F) \
+ (! (ISSLASH ((F)[0]) || FILE_SYSTEM_PREFIX_LEN (F) != 0))
#endif /* DOSNAME_H_ */
