From 5e885aedc03fcf8c13fc9652c8e76da02e3a83d6 Mon Sep 17 00:00:00 2001 From: Ingo Schwarze Date: Tue, 2 Aug 2016 11:09:46 +0000 Subject: POSIX allows PATH_MAX to not be defined, meaning "unlimited". Found by Aaron M. Ucko on the GNU Hurd, via Bdale Garbee, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829624 Also add EFTYPE at two places where it was forgotten. --- test-PATH_MAX.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 test-PATH_MAX.c (limited to 'test-PATH_MAX.c') diff --git a/test-PATH_MAX.c b/test-PATH_MAX.c new file mode 100644 index 00000000..99bcc0b4 --- /dev/null +++ b/test-PATH_MAX.c @@ -0,0 +1,30 @@ +/* + * POSIX allows PATH_MAX to not be defined, see + * http://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html; + * the GNU Hurd is an example of a system not having it. + * + * Arguably, it would be better to test sysconf(_SC_PATH_MAX), + * but since the individual *.c files include "config.h" before + * , overriding an excessive value of PATH_MAX from + * "config.h" is impossible anyway, so for now, the simplest + * fix is to provide a value only on systems not having any. + * So far, we encountered no system defining PATH_MAX to an + * impractically large value, even though POSIX explicitly + * allows that. + * + * The real fix would be to replace all static buffers of size + * PATH_MAX by dynamically allocated buffers. But that is + * somewhat intrusive because it touches several files and + * because it requires changing struct mlink in mandocdb.c. + * So i'm postponing that for now. + */ + +#include +#include + +int +main(void) +{ + printf("PATH_MAX is defined to be %ld\n", (long)PATH_MAX); + return 0; +} -- cgit v1.2.3