Комментарии 22
Это позволит нам не волноваться о таких странных платформах, не писать код и проверки на те случаи, когда большие типы оказываются не очень большими. Такой код сегодня сложно верифицировать, поскольку практически никто уже не пользуется такими компиляторами/системами.
почему-то напомнило историю, когда Эппл взяла и отказалась от поддержки 32 битных приложений. причем настолько, что даже убрала их из магазина приложений. то, что такие приложения устарели, но все ещё работали, и, зачастую, так и не были обновлены разработчиками для поддержки 64 бит, их не волновало.
Это отличие между энтузиастами, ставившими ux во главу угла, и капиталистами максимизирующими прибыль
И в чем пример? Вы опустили контекст - эпл делают продукт которым пользуются, и решения принимаются исходя из этого. И вы как энтузиаст делали что хотели, возможно для вас и других введение новых фич было лучшим для ux, чем консерватизм.
Дихотомия ложная, но лишь в очень редких случаях, когда улучшение ux сопутствует максимизации прибыли. И даже это от терминологии зависит
Когда кто-то напишет какой-нибудь xurl на новом стандарте или даже языке, и он станет более популярным, чем curl, вопрос закроется сам собой.
Так уже есть httpie — на питончике написанный, у него очень приятный UI, с кучей плагинов к тому же. Например, только с помощью стороннего плагина к нему (и немного багфиксинга) я смог сделать хитрую подпись multipart-запросов на AWS — никто больше не умел, ни curl, ни postman.
Всем он хорош, но вот взять и скомпилить статически его не выйдет. А иногда надо нормальный curl там, где нельзя поставить, но можно подсунуть бинарник...
Может быть, подойдёт такой вариант?
% nix bundle nixpkgs#httpie
% ls -lHh httpie
-r-xr-xr-x 2 root root 70M Jan 1 1970 httpie
% ./httpie --version
3.2.1Для запуска нужно лишь работающий /bin/sh и ничего более.
Попробуйте curlie. Тот же httpie, но на go написан
https://github.com/rs/curlie/blob/master/main.go#L141
Если мне всё равно придётся собирать curl - накой мне обёртка?
Сейчас бы написали на питоне, и сказали бы - купите больше памяти и ядер процессора.
Можно только порадоваться, что в нашем профессиональном мире остались люди, которые не несутся за всем новомодным и «современным», словно их сзади кнутом подгоняет безумный кучер, а подходят к вопросу взвешенно и вдумчиво.
Между тем, есть и обратные примеры: в какой-то момент мне стало интересно, почему, начиная с определённой версии, Process Explorer Руссиновича перестал адекватно работать на Windows XP. Это была именно та версия, в которой пофиксили баг с заморозкой/разморозкой потовков. Пришлось взять дизассемблер/отладчик и пореверсить программу, чтобы выявить, какие же такие новые функции новых ОС ей теперь стали нужны для правильной работы. Оказалось, что — никакие. Ограничение было чисто искусственным и нелепым. Я написал Руссиновичу свои соображения, как проблема несовместимости может быть исправлена одной строчкой, на что она даде ответил что-то вроде «да, может, но мы не будем это чинить просто потому, что не будем и всё».
Возможно, об этом можно написать на Хабр небольшую статью.
C11 содержит atomic'и, поэтому переход на него довольно рационален для проектов с многопоточностью. Например, OCaml 5.х работает только на C11, отбрасывая всякие legacy unix платформы.
Коллеги, раз такая тема, подскажите. Пишу на С уже несколько лет. Но хочется знать язык прям от и до, наизнанку. Про ABI, про память, как работают функции, ассемблер. Что почитать?
Зачем тут писать про httpie, когда curl — это не только консольная утилитка curl, но ещё и libcurl — библиотека, которую под капотом использует огромное количество проектов?
Зачем нужно сравнивать тёплое с мягким?
Классический пример статьи "ни о чем". Нет такого понятия как "переход на С99" (или на любой другой стандарт) у вас не было необходимости мучительно "эмулировать" те возможности, которые новая спецификация предоставляет из коробки.
P.S. Также, по странностям перевода возникает подозрение, что автор перевода не совсем хорошо разбирается в фичах языка. Перевести "designated initializers" как "специальные инициализаторы"... Навскидку совсем непонятно, о чем идет речь.
В то же время, я думаю, такая необходимость у авторов curl скорее всего в какой-то мере была (чисто теоретически предположу, например, использование struct hack вместо предоставляемого C99 flexible array member, использование именованных временных переменных вместо составных литералов, функциональные макросы вместо inline-функций, snprintf), но им просто лень всем этим заниматься. Работает - ну и пусть.
CURL: почему проект, которому четверть века, не торопится переходить на C99