Проект curl основан на фундаменте, заложенном в конце 1996 года инструментом под названием httpget.
ANSI C, ставший известным как C89
В 1996 году было не так много хороших альтернатив для создания небольшого и эффективного инструмента командной строки для передачи данных через Интернет. Я не хочу сказать, что C был единственным имевшимся языком, но для меня выбор был прост, и, честно говоря, когда начался этот путь, я даже не думал о каких-то других языках. Мы называли версию этого языка ANSI C, чтобы отличать его от «старорежимного» C K&R. Версию ANSI C позже переименовали в C89 (иногда её называют C90, и это сбивает с толку).
В 2000 году мы выпустили libcurl — библиотеку, предоставляющую всем желающим суперсилы передачи данных через Интернет. Это ещё сильнее оправдывало выбор C. Благодаря C мы могли без проблем предоставить стабильный API/ABI, чего в то время не мог обеспечить даже C++. К тому же это был достаточно портируемый язык, поэтому мы смогли перенести curl и libcurl практически на все современные операционные системы.
Поскольку я хотел, чтобы curl и libcurl предоставляли возможности системного уровня, и нацеливался на максимально широкое распространение, их нельзя было написать ни на одном из высокоуровневых языков наподобие Perl, Python или им подобных. Из-за этого они стали бы слишком большими и тащили за собой слишком много «лишнего багажа».
Я убеждён, что использование (консервативного) C для разработки curl — ключевой фактор его успеха и возможности использования его «где угодно».
C99
Стандарт C99 был опубликован (сюрприз!) в 1999 году, однако его освоение компиляторами заняло долгое время, что мешало нам его использовать. Мы хотели, чтобы curl был доступен «повсюду», поэтому пока одни из самых популярных компиляторов не поддерживают C99, мы даже не рассматривали возможность смены версии C, поскольку это могло бы подвергнуть риску распространение и использование curl.
Позже всех из популярных компиляторов освоил C99 компилятор Microsoft Visual C++, который реализовал этот стандарт должным образом только в 2015 году, а в 2019 году улучшил его поддержку. Большое количество наших пользователей/разработчиков по-прежнему придерживалось старых версий MSVC, поэтому не все пользователи этого пакета могут собирать программы на C99 даже сегодня, в конце 2022 года.
C11, C17 и дальше
Тем временем, ISO C Working Group продолжает выдавать обновления языка C. Был выпущен C11, появился C17, а теперь они работают над находящейся в рассмотрении версией C2x, которую, предположительно, назовут C23.
Повысить требования для curl?
Мы понимаем, что другие популярные проекты на языке C движутся вперёд, подняв свои требования до версии C99 или выше. Среди них ядро Linux, проект git и многие другие.
Обсуждение повышения версии C происходило и в рассылке libcurl, в частности, мы уже запланировали выпуск версии 8 весной 2023 года, поэтому теоретически это мог бы быть подходящий момент для внесения подобных изменений.
Какие возможности C99 могут улучшить проект наподобие curl? Самые интересные части C99, которые могут повлиять на код curl, на мой взгляд, следующие:
- Комментарии
// - Стандартный идентификатор
__func__ - Булевый тип в
<stdbool.h> - Специальные инициализаторы struct
- Пустые аргументы макросов
- Расширенные типы integer в
<inttypes.h>и<stdint.h> - Динамические члены массивов (массивы нулевого размера)
- inline-функции
- Правила типов целочисленных констант
- Смешанные объявления и код
- Тип
long longи библиотечные функции - Семейство функций
snprintf() - Допустимая висячая запятая в объявлении enum
- Макросы vararg
- Массивы переменной длины
То есть да, мы можем использовать множество крутых штук. Но действительно ли они нам нужны?
Для многих из представленных выше возможностей у нас уже есть достойные и функциональные замены. Многие из возможностей для нас не важны. Остальные могут просто отвлекать нас от дела.
При безусловном использовании C99 в коде curl возникает угроза того, что люди начнут переписывать разные части инструмента, поэтому нам пришлось двигаться аккуратно и открывать доступ к новым возможностям C99 постепенно. Именно так же поступает и проект git. Сложность такого подхода в том, что сложно проверить соответствие допустимых и используемых возможностей, поскольку у существующего инструментария обычно нет такой функциональности.
Также задавался вопрос: если мы рассматриваем возможность повышения требований, то не стоит ли нам поднять их до C11, а не останавливаться на C99?
Не сейчас
В конечном итоге, ни один человек пока так и не смог чётко донести, какие преимущества такое повышение требований к версии C даст проекту curl. В основном мы видим риск в том, что окажемся затянутыми в довольно несущественные обсуждения, и что изменения не особо продвинут проект вперёд как с точки зрения возможностей, так и качества/безопасности.
Думаю, у нас есть гораздо более полезные занятия и гораздо более стоящие цели, на которые следует тратить свою энергию; они действительно улучшат проект и разовьют его.
Например, это улучшение набора тестов, увеличение площади покрытия тестами, возможность выполнения большего объёма кода фаззерами.
Умеренные изменения в требованиях
Мы решили, что начиная с curl 8 будем требовать, чтобы компилятор поддерживал 64-битный тип данных. Его не существовало в исходной версии C89, он был добавлен в C99. Однако уже не осталось современных компиляторов, не поддерживающих его.
Это позволит нам не волноваться о таких странных платформах, не писать код и проверки на те случаи, когда большие типы оказываются не очень большими. Такой код сегодня сложно верифицировать, поскольку практически никто уже не пользуется такими компиляторами/системами.
Возможно, именно так мы продолжим адаптироваться и в дальнейшем использовать отдельные возможности, появившиеся после C89: выбирая их одну за другой и постепенно адаптируя их.
Мы отказались от C99 не навсегда
Я уверен, что в будущем мы снова поднимем эту тему на обсуждение. Мы не закрыли эту дверь навсегда, и наши требования не высечены в камне. Просто в настоящий момент мы решили, что не хотим преследовать эту цель. Возможно, это произойдёт в будущем.
Другие языки
Мы не рассматриваем возможность перехода или переписывания curl на какой-то другой язык.
