>> 1) совместимость: strcat/strcpy, очевидно, куда опаснее, и тем не менее они всё же поддерживаются
> Это - ANSI C. Плох он или хорош - это тем не
> менее стандарт. Так что - приходится.А подумать? В стандарте оно до сих пор именно по причине совместимости.
>> 2) не включать на основании "тупое использование повредит" - это не Unix-way подход, а виндовый. Для того, кто знает, что делает, возможность должна присутствовать. В конце концов, в ядре и glib она есть, а в glibc нету, с какой стати Дреппер считает себя умнее?..
> А почему собственно дядя Дреппер - глупее? Почему strlcpy есть в ядре
> - понятно. Уже готовые 3d party драйвера. Тут хочешь не хочешь,
> но включишь. Не до жиру. Почему в glib есть - тоже
> понятно. Туда какой только гадости не пихают - все, до чего
> руки дотянутся. Что тут удивляться.. А вот зачем пихать нестандартную и
> вызывающую вполне обоснованные нарекания strlcpy в стандартную, замечу, libc - это
Дядя Дреппер _считает_ себя умнее и вправе указывать другим. У него и других идиосинкразий хватает, впрочем, об этом лучше netch расскажет. Кроме glib, еще есть кеды, самба и rsync - они тоже идиоты гадость пихают, да? Ну и "готовые 3d party" - это ровно та же причина, совместимость. Приложений-то, чай, побольше с этой функцией будет, чем драйверов.
На самом деле за позицией Дреппера совершенно явно торчат уши "оно придумано не нами, а в BSD" - иначе бы в обосновании была не идеологически-политическая хрень (а у *никсов, напомню, философия Tools, not policy), а гораздо более практичное "оно по-разному работает на BSD и солярке, чего нам выбрать-то?".
> Иначе уже завтра (злая) половина гнутых
> поделий будет обвешана такими мелкими 'стандартными' (в одной системе) хаками, как
> елка игрушками. Вот включат strlibc в ANSI C/POSIX - пожалуйста.
Вы, может быть, сильно удивитесь, но они _уже_ обвешаны хаками от одной системы, причем как бы уже не половина, а большинство софта написаны непортабельно, т.е. на отличных от Linux системах собираются только с напильником.
