25.06.2026 07:00
Из ядра Linux выпилили strncpy 19 июня Линус Торвальдс принял merge, окончательно удаливший из ядра функцию strncpy.
Из ядра Linux выпилили strncpy
19 июня Линус Торвальдс принял merge, окончательно удаливший из ядра функцию strncpy. На это ушло шесть лет работы, 362 коммита и 70 разработчиков. Пример того, почему просто заменить небезопасную функцию в C вовсе не просто.
Буква «n» в названии создаёт иллюзию контроля: strncpy(dst, src, n) копирует максимум n байт. Однако документация предупреждает, что это не строковая функция, она создаёт null-padded character sequence. Появившись в AT&T Unix около 1979 года для работы с именами файлов в директориях (поля фиксированной ширины), strncpy десятилетиями использовалась в обычном коде как безопасная замена strcpy. Но если длина источника >= n, терминальный \0 не ставится, и любой strlen или printk улетит за буфер. Если источник короче n, то весь остаток до n забивается нулями, что порождает ненужную нагрузку.
Заменить strncpy одной функцией невозможно: под разные намерения нужен разный инструмент:
strscpy() — для нормальной строки с терминатором.
strscpy_pad() — то же с обнулением хвоста.
strtomem() / strtomem_pad() — для полей фиксированной ширины без терминатора.
memcpy_and_pad() — для bounded-копии из источника, который может не иметь завершающего нуля.
memtostr() / memtostr_pad() — обратный случай.
memcpy() — если это вообще не строка.
Один и тот же вызов strncpy требовал ручного чтения контекста: строка это или бинарное поле, нужен ли ноль, нужен ли padding. 362 раза, и каждый раз разное решение.
В вашей кодовой базе strncpy, скорее всего, всё ещё живёт как безопасный вариант. Это не баг в трекере, это код, который надо перечитать. И главная работа будет не в замене функции, а в том, чтобы понять, что лежит в каждом буфере. Ядру на это понадобилось шесть лет и 70 человек — на API, который выглядел как безопасный десятилетиями.
🐧Обсудить в Чате Linux
19 июня Линус Торвальдс принял merge, окончательно удаливший из ядра функцию strncpy. На это ушло шесть лет работы, 362 коммита и 70 разработчиков. Пример того, почему просто заменить небезопасную функцию в C вовсе не просто.
Буква «n» в названии создаёт иллюзию контроля: strncpy(dst, src, n) копирует максимум n байт. Однако документация предупреждает, что это не строковая функция, она создаёт null-padded character sequence. Появившись в AT&T Unix около 1979 года для работы с именами файлов в директориях (поля фиксированной ширины), strncpy десятилетиями использовалась в обычном коде как безопасная замена strcpy. Но если длина источника >= n, терминальный \0 не ставится, и любой strlen или printk улетит за буфер. Если источник короче n, то весь остаток до n забивается нулями, что порождает ненужную нагрузку.
Заменить strncpy одной функцией невозможно: под разные намерения нужен разный инструмент:
strscpy() — для нормальной строки с терминатором.
strscpy_pad() — то же с обнулением хвоста.
strtomem() / strtomem_pad() — для полей фиксированной ширины без терминатора.
memcpy_and_pad() — для bounded-копии из источника, который может не иметь завершающего нуля.
memtostr() / memtostr_pad() — обратный случай.
memcpy() — если это вообще не строка.
Один и тот же вызов strncpy требовал ручного чтения контекста: строка это или бинарное поле, нужен ли ноль, нужен ли padding. 362 раза, и каждый раз разное решение.
В вашей кодовой базе strncpy, скорее всего, всё ещё живёт как безопасный вариант. Это не баг в трекере, это код, который надо перечитать. И главная работа будет не в замене функции, а в том, чтобы понять, что лежит в каждом буфере. Ядру на это понадобилось шесть лет и 70 человек — на API, который выглядел как безопасный десятилетиями.
🐧Обсудить в Чате Linux