Бегло пробежал стандарт и исходники. 100 в стадарте не нашел. Зато нашел, что сандарт во всю ссылается на PATH_MAX (что есть длина пути без файла).
Solaris нет, у кого есть пусть глянут
FreeBSD 8.0 - /usr/include/sys/syslimits.h:
#define NAME_MAX 255 /* max bytes in a file name */
#define PATH_MAX 1024 /* max bytes in pathname */И POSIX тоже есть:
/usr/include/limits.h:#define _POSIX_PATH_MAX 256
Итого 1024+255=1275 (минус 2 байта на \0 в каждой переменной + 1 байт на \0 в результирующей) - длина пути с именем файла 1274.
Но там же, есть еще объявление:
/usr/include/limits.h:#define _POSIX_PATH_MAX 256
CentOS 5.4 Чесное слово - зоопарк. Там этих define штук 30. Взял из тех же limits (как наиболее похожих на системное):
/usr/include/linux/limits.h:
#define PATH_MAX 4096 /* # chars in a path name including nul */
Тут тоже Posix есть:
/usr/include/bits/posix1_lim.h:
#define _POSIX_PATH_MAX 256
NAME_MAX или нечто подобное не искал - и так ясно, что длинее, чем в том же FreeBSD и posix.
Сам tar (ни posix ни bsd) не ковырял на предмет откуда они лимиты берут из системы или сами придумывают (в этом случае вообще тушите свет).
Итого, POSIX по сути лимиты особо не регламентирует (по крайней мере определения PATH_MAX я не нашел, смотрел бегло, так что может оно и есть) - что хош, то и пользуй (по крайней мере в Linux и FreeBSD использются свои лимиты), хотя в обеих системах какое-то определение есть (256). И тут дело похоже не в реализации tar (gnu/bsd), а системных лимитах. Если gnu tar написан нормально и он использует системные определения лимитов (что вобщем логично), то на BSD допустимая длина пути в архиве созданном gnu tar-ом будет меньше, чем на linux.
Кстати, получается Windows со своим лимитов в 256 байтов на длину был более posix совместим :) Не знаю, может уже и увеличили, не слежу...
Но вот что забавно, на том CentOS, я выкопал:
/usr/include/linux/un.h:#define UNIX_PATH_MAX 108
/usr/include/linux/un.h: char sun_path[UNIX_PATH_MAX]; /* pathname */
И судя по словам Unix и sun - на каких-то Solaris, возможно, системный лимит был 108 байтов. Так что уважаемый, если человек что-то говорит, совсем не обязательно что это ложь, надо просто разобраться.
По сути топика.
Разница-то в основном не в лимитах, а в реализации, возможностях, ключах. И мне непонятно, почему набор инструментов, для настройки пакета под конкретную платформу (где предусмотрена поддержка не только gnu платформ!) требует определенных именно gnu utilities. Да, я знаю, что BSD find беднее GNU find, да bash не идет в базовой системе FreeBSD, но при этом, почему-то, некоторые утилиты требуют его (как и возможностей gnu-utils), хотя, им было бы достаточно функциональности простого sh.
Мне кажется, что разработчикам automake/autoconf (раз уж они поддерживают не только gnu платформы) стоило бы добавить поддержку инструментов используемых по умолчанию на других распространенных платформах, при этом оставив возможность требования наличия определенной реализации инструментов конкретным пакетом. В таком случае, это уменьшит кол-во проблем при портировании, увеличит совместимость ПО на разных платформах. И вообще, решит кучу проблем.
С отправкой патчей я думаю фокус не пройдет, потому что, скорее всего, он просто менят путь с gnu на openbsd specific (например), и при внесении такого патча в код autotools все сломается на gnu. Тут нужен другой подход - нужно, чтобы разработчики autotools обратили внимание на проблему и добавили соответствующий функционал, а не просто поменяли шило на мыло. Собственно, он и обратил их внимание.
