curl уязвим, но я вам не скажу, какие версии

подавляющая масса современного кода Хотя бы ядро Linux

Я вопрошал про подавляющую массу современного кода написанного на чем-то крому сишечки. И тут ядро линукса.

Это что, троллинг тупизной?

Допускаю, что у тебя потеря контекста?

что микроконтроллеры до сих пор остаются весьма ненадежными устройствами

в чем ненадежность?

Хватить лозунги вбрасывать, поясняй свои вбросы.

Я ничего не имею против раста, но кроме чего-то там где-то было про прошивку для какой-то камеры чего-то ничего не видно

Как я понимаю, эмбедед – довольно инертная и консервативная среда. Пока производитель почешется запилить SDK под раст и добавить необходимые оптимизации в LLVM – может пройти много времени.

Давай простой пример. Вот коллега просит меня на мк типа stm32f1xx просит написать прошивку для включения подсветки в мерседесе. Все тупо, слушаем кан, прилетела наша цифирь, мы зажгли лампочку. Что и где мне взять чтобы все это написать на чистом расте без лишных зависимостей?

Официальной поддержки раста в их SDK нет. Есть проекты от энтузиастов. Похоже, «без лишних зависимостей» – это только сишка, на данный момент. Но я не говорил, что раст может полностью заменить Си в эмбедеде вотпрямщас. Я говорил, что нет принципиальных ограничений для использования в эмбедеде менее топорных языков, и никакой особенной «близостью к железу» или «оптимальным уровнем абстракции» сишка не обладает.

1. basic auth это один заголовок - никакой логики в коде он не требует, чисто текстовая вставка

А что это тогда эти бесовские картинки на MDN делают? И ещё какие-то rfc7235 понаписали с кучей слов, описанием разных заголовков.

Где добавить, зачем? Есть конкретная задача, выполнять надо её

«Работало без аутентификации, но обстоятельства изменились и надо срочно добавить аутентификацию»

Но большинство уязвимостей в индустрии вызваны именно устройством C/C++

Это в какой-то отдельно взятой индустрии, где именно C и C++ нужны. В вебе это, очевидно, не так.

Никто же не хейтит ассемблер за то, что он может сделать больно?

Ни один адекватный человек не предлагает писать на асме все. Подавляющая масса современного кода написана на нормальных языках

Дальше. Что такое «подавляющая масса современного кода»?

Хотя бы ядро Linux, под управлением которого работает лоровский сервер и компьютер, которым ты сейчас пользуешься. По гитхабовской статистике выходит, что только 0.8 процента кода написано на асме

Если я не ошибаюсь, последовательность обсуждения асма выглядит именно так. Видимо, мы друг друга не поняли.

Еще одно поколение кейла и вендостудии взрасло.

Давай решение, чтобы можно было код писать в mcedit и собирать его чем-то, чей результат можно прошить в мк. Не надо IDE и прочих плагинов с подсветкой. Только голая консоль только хардкор!

Ну и заход про консерватизм мимо кассы. Опять танцору яйца мешают.

Подожди. Я спорил с тем, что сишечка обладает особенной близостью к железу или «оптимальным уровнем абстракции». Кроме сишки есть много языков, которые подходят для эмбедеда или для системного программирования. То, что язык Си стал распространенным в этой нише – не признак высокого качества языка, но следствие нетехнических обстоятельств.

Ну и заход про консерватизм мимо кассы. Опять танцору яйца мешают

Какие нахрен яйца, если производитель не торопится сделать растовый SDK для своего микроконтроллера?

Давай решение, чтобы можно было код писать в mcedit и собирать его чем-то, чей результат можно прошить в мк. Не надо IDE и прочих плагинов с подсветкой. Только голая консоль только хардкор!

Для ядра Linux ты уже сейчас можешь писать дрова в голой консоли.

Давай решение, чтобы можно было код писать в mcedit и собирать его чем-то, чей результат можно прошить в мк

https://github.com/rust-embedded/awesome-embedded-rust

главная уязвимость curl это пользователи, исполняющие curl | bash

главная уязвимость curl это пользователи, исполняющие curl | bash

To install Rust, if you are running Unix,
run the following in your terminal, then follow the on-screen instructions.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Просто плюсы, особенно в последних версиях, очень далеко уходят в своих абстракциях от железа и системы. Это ни хорошо ни плохо, просто плюсы это другой язык, который местами может компилить сишный код, но это другой язык.

Я скажу странную вещь, но защищенный режим работы userspace-а примерно похож на работу виртуальной машины, потому про какую мы там близость к железу и системе говорим — не понимаю. Причем, этот уровень абстракции мог иметь иную модель, не обязательно один в один моделирующий железяку.

Ну и заход про консерватизм мимо кассы. Опять танцору яйца мешают.

К сожалению, существование легаси инфраструктуры мешает нововведениям. И это не только в программировании так. Вот в ЖД транспорте, например. В Германии - медленные электрички, экспрессы хорошо если 160км/ч дадут, строительство высокоскоростной трассы Берлин-Мюнхен - колоссальное достижение, и даже там была какая-то поломка, когда Меркель первый раз поехала. И с другой стороны Китай, сколько там уже максималка, 400км/ч? А потому что не было легаси, такого разлапистого, как в Европе, поняла была чистая.

Вот тебе пример: .h .c.

Oh my fucking god! Make me unsee it!

Код пишет кожанный мешок, а он не может рассуждая на уровне std::cout думать к какому ассму это приведет.

95% кода выполняется 5% времени, потому обычно пофигу вообще.

Я согласен с тем, что абстракции могут быть вредны, но это связано не с абстракциями, а с убогостью самого C++, в котором любые высокоуровневые абстракции скатываются в говно из шаблонов с нечитаемыми сообщениями об ошибках — то есть, речь не про производительность выполнения кода, а про производительность разработки.

вполне возможно, что это действительно хорошее решение, несмотря на твой саркастический тон. Конкретные числа (11гб, 100гб) ни о чём не говорят, пока неизвестно чем же занимается этот сервер и в каких масштабах.

Хостит котиков и сиськи. Но в данном случае он не делает ничего, он вообще пустой.

Тогда потом, когда oom-killer научится хорошему поведению, они сразу будут готовы к 100% стабильной работе. А ещё может быть у oom-killer-а есть настройка важных процессов которые нельзя трогать пока есть другие.

Есть oom_score_adj, но тогда система сдохнет целиком в случае, если оконный менеджер выжрет всю память.

Я конечно понимаю, что у сишки тупо больше бэкграунд в виде миллиардов человеко-часов. Тем не менее, если раст так хорош, почему все на него мгновенно не перепрыгнули?

Раст говно потому, что переусложнен и очень медленно компилируется, что, в свою очередь, случилось потому, что его писали крестовики, для которых переусложненность и медленная компиляция являются нормой. А беда от того, что подавляющее большинство инженеров в IT необучаемы, потому с пеной у рта будут отстаивать преимуещства знакомого говна и не замечать его запаха, при этом изыскивая мельчайшие «недостатки» в альтернативах.

Так что для крестовика Rust — идеальный язык, недостатков он в нём не видит. Ту же историю ты можешь увидеть с сишниками.

Почему в вебе все прыгают как ужаленые с одного фреймворка на другой, из-за лишней гомеопатической дозы сахарочка. А тут никак?

На реакте очень даже бодро пишут до сих пор. Но, да, ниша относительно молодая, там много желторотых, которые не знают ни одного фреймворка. Справедливости ради, писать код они толком не умеют тоже. И готовых решений там как кот наплакал, так что с объективной инерцией сишных решений оно не сравнится.

Как будто что-то плохое. Full Disclosure – единственный путь!

Нет смысла использовать код, 90% которого тебе не нужны, иначе это и есть говнокодинг, по-моему

Какие 90%? Ты предлагаешь на каждый случай использования списка новую реализацию городить?

Нет, я только предлагаю не использовать толстую библиотеку, если нужна малая часть её функциональности. Список это не тот случай.

Можно развернуть утверждения про «тупиковость» и не «следуют модели Тьюринга». Ну и очень хочется послушать мысли про светлое будущее, конечно.

Можно. В одном из недавних тредов я затрагивал уже имеющиеся альтернативы, эмулируемые на нейросетях, но на самом деле аналогичную модель обработки данных можно применять без эмуляции, и даже есть специализированные асики конкретно для нейросетей. Процессоры внутри себя использую смешанную событийно-пошаговую модель выполнения, которую можно воображаемо рассматривать как очень большое число машин тьюринга, но только из-за того, что они тонко отлажены для имитации машин тьюринга — в своем сыром виде это чисто событийные вычислители, которые довольно тонко синхронизированы по некоему сигналу.

Я когда-то даже приводил расчеты производительности вычислений на CPU, GPGPU, и ASIC-ах, там соотношение было порядка 1:50:1000, то есть, современные процессоры вопиюще неэффективны.

Ещё раз повторю: basic auth это ОДИН заголовок, который начинается с «Authorization: Basic». Всё остальное это сахар для интерактивных браузеров и в автономных клиентах не нужно.

rfc7235

С таким номером даже смотреть не буду. Всё что надо знать про http с номерами меньше 4000.

Я когда-то даже приводил расчеты производительности вычислений на CPU, GPGPU, и ASIC-ах, там соотношение было порядка 1:50:1000, то есть, современные процессоры вопиюще неэффективны.

CPU - универсальны. На GPGPU эффективно считать задачи с массовым SIMD. Что попало на них уже не запустишь. ASIC-и вообще делают под конкретную задачу. Максимум эффективности, минимум универсальности.

Реализация просто списка - это около 15 строчек кода. Определённо не стоит для этого использовать никакие библиотеки. Даже более того, во многих случаях не стоит выделять реализацию списка в отдельную сущность от реализации его полезной нагрузки.

Цэ – это типичный ЯП высокого уровня, основная идея создания которого – простота компилятора, плюс несколько синтаксических конструкций под систему команд PDP-11.
Какой-то дебил однажды придумал ставить сишку и асм чуть ли не в один ряд, и пошло-поехало.

Вот для этого я изучаю историю. Си — это изначально препроцессор для асма, то есть «препроцессор Си => препроцессор асма => асм => линкер», потом два центральных шага стали одним цельным компилятором. Огромное количество артефактов сишки вызвано именно тем, что это просто-напросто нашлёпка над асмом, в том числе нуль-терминированные строки были родными для асма PDP — K&R реально совсем ничего не изобретали, они просто сделали классическое «херак-херак — и в продакшен».

В этом плане Си БЕЗ препроцессора — язык промежуточного уровня, нашлёпка на асм, даже до фортранов-коболов оно не дотягивает, компилятор Си получает на вход программу, которая близка к ассемблерному коду. Но вот наличие препроцессора, внезапно, делает даже ассемблер PDP языком высокого уровня (там можно было препроцессить на лиспе, ололо).

Чем сишка на современных архитектурах отличается от того же паскаля? Исключительно разнообразными знаками препинания вместо английских слов. Ну и тоннами UB, конечно.

У тебя всё верх ногами: паскаль было жавой своего времени, максимально платформонезависимым ЯП с настолько безопасной памятью, насколько было приемлимо для того времени (полный GC был дорог). Это потом он начал дрейфовать в сторону C/C++, и вот уже FPC разрешает арифметику над Pointer, которую Delphi, если я не ошибаюсь, запрешает до сих пор (разрешена только типизованная).

Звучит как эфир и торсионные поля. Есть ссылку на статью про такие вычислители?

во многих случаях не стоит выделять реализацию списка в отдельную сущность от реализации его полезной нагрузки

Т.е. встроить данные в алгоритм?

без оптимизаций код на C++ очень медленно ползает

Относительно чего?

Относительно всего, даже питон кое-где быстрее бегает, чем неоптимизированный код C++ на сложных классах и шаблонах. Особенно больно каким-нибудь разрабам игор, для которых производительность неоптимизированного кода просто непримелима, потому даже отлаживают они на минимальных уровнях оптимизации.

Нет, я только предлагаю не использовать толстую библиотеку

Блин. Мы говорим об обычном динамическом массиве. Откуда там толстая реализация? Чему там быть-толстым то? Посмотри хоть документацию джавовского ArrayList. Никаких страшных «избыточных функций» там нет

Фу так словами жонглировать

Мы говорим об обычном динамическом массиве

Я думал, что про libcurl.

Только ты забыл про " современный код" на «нормальных языках». При этом сишечку за нормалтный язык не считаешь, но в качестве примера приводишь крупнейший проект на сишечке. Или это другое?

Чтобы сделать поддержку меги8 от атмела, да даже стм32 достаточно даташита на него, а не поддержки производителя.

Потом уже увидел ссыль на гитхаб. Как нидь запилю хеловорд на меге.

В контексте написания любой более-менне сложной программы асм менее адекватен, чем сишка :) Но вообще ты меня подловил. Надо выражать свои мысли понятней и не допускать расплывчатых формулировок

Даже более того, во многих случаях не стоит выделять реализацию списка в отдельную сущность от реализации его полезной нагрузки

Ага. Чтобы каждый раз выполнять мартышкину работу и писать одно и то же стопицот раз подряд. Чтобы в твоем говнокоде другой программист не смог разобраться без поллитры. Да и ты сам через полгода.

Твоя фраза непонятна. Данные хранятся в сегменте (секции итд как оно там называется сейчас) данных, алгоритм - в сегменте кода.

Интегрировать вспомогательные списочные функции в основной алгоритм. Где даже вручную заинлайнить.

Это действительно даёт какой-то профит?

Просто сравни ту жуткую писанину, ссылку на которую ты здесь кидал, и код из того же sway. Там хоть и есть типичный обосрамс с выделением памяти, но в целом код гораздо понятней.

https://github.com/swaywm/sway/blob/master/common/list.c

https://github.com/swaywm/sway/blob/master/include/list.h

Там нет жуткой писанины, просто тебе стиль кода не по вкусу (кстати если уберёшь оттуда все assert-ы, то станет ещё красивее и раза в 2 компактнее, но они нужны как раз в целях проактивного противодействия багам, впрочем ни разу ещё не сработали). Лично мне все понятно и интуитивно. Открыл наугад несколько исходников sway, тоже выглядит норм.

Это реально единицы строк кода, и делать например реализацию foreach с колбеком зачастую менее желательно, чем просто по месту написать что-то типа for(i=start; i; i=i->next) в явном виде.

Даёт профит в плане прозрачности работы кода методом уменьшения количества сущностей. Ну, это не везде так надо, но часто удобно. В случае со списками за универсальность и абстрагирование от полезной нагрузки приходится платить кратным увеличением количества кода, а на стороне «потребителя» не особо что-то изменится.

Ну, вижу. И каких комментариев ты ждёшь? Сделано в целом приемлемо, но сфера применения не совсем понятна.

Хотя, list_free может например молча устроить memory leak. А если он за этим не следит, то непонятно зачем вообще функция обёртка над двумя free. А да, нашёл внизу list_free_items_and_destroy, но тогда новые вопросы:

1) почему тогда list_free не static, раз уж её сделали отдельной, а показывать наружу надо вторую?

2) получается этот list годится только как список плоских блоков данных, аллоцированных malloc-ом, сложное в него пихать нельзя, а если и пихать - придётся нарушать и так неважную инкапсуляцию и реализовывать где-то снаружи альтернативное list_free_items_and_destroy.

А ещё я бы не стал аллоцирование самого list_t сюда вообще включать, т.к. эта тривиальная структура из 12-16 байт почти не отличается по размеру от указателя размером 4-8 байт, и много где её желательно было бы хранить статически.

Аааа! capacity/length мало того что не size_t так ещё и signed! Стандартный дефект твоих любимых «сишников» в самом плохом смысле этого слова, традиционный для в 80-х годов. (впрочем, признаю, в моём .c файле тоже int не к месту в одном месте, но переполнение в нём невозможно т.к. с ним кроме инкремента от 0 до заранее заданной константы ничего не делается) Нет проверки на переполнение когда capacity умножается на sizeof(void*).

Ну, про realloc ты уже писал. А ещё на мой взгляд разширение массива методом умножения на 2 не всегда хорошо (но это вкусы), и там опять нет проверки на переполнение (а это уже явно плохо).

list_move_to_end() в виде list_del+list_add с одной стороны зрительно замусоривает код, с другой вызывает ненужное list_resize в середине, а могли бы вставить туда memmove + перемещение одного item-а в явном виде.

Дальше лень смотреть.

А да, я не про те списки думал. То что в этом файле я обычно массивами называю. А списками - односвязные или двусвязные.

в чем ненадежность?
Хватить лозунги вбрасывать, поясняй свои вбросы.

Лень, я никому не обязан, могу только если очень сильно попросите...

Ладно, так и быть... Есть такой язык программирования Brainfuck. Это типичная тьюринг машина, котора полностью детерминирована и может выполнить алгоритм любой сложности, но:
1. Человек всегда ошибается, причем, тем чаще ошибается, что сложнее задачи выполняет, то есть, написанная неудобным инструментом программа обречена быть неправильной, несмотря на то, что эта неправильная программа исполняется строго по алгоритму;
2. Если у тебя виснет MS Word, то как-то и похеру. Если у тебя виснет аппарат искуственного дыхания, то кто-то умирает. Помимо выживания после ошибки при точном исполнении алгоритма, по-настоящему надежному контроллеру нужно уметь выживать, например, после сбоя какого-то устройства. То есть, не просто способность всегда работать правильно, а способность ВОССТАНАВЛИВАТЬСЯ ПОСЛЕ ОТКАЗА — это ключевое условие для создания по-настоящему надежного контроллера.

Проблема в том, что эмбед давно похож на младшего брата, донашивающего вещи за старшим. То есть это не инструменты, разработанные специально для микроконтроллеров, это не копеечные 32-ядерные армы по 50 тыс транзисторов/ядро со сверхнизким потреблением, где каждое ядро в реальном времени обрабатывает микрозадачу по своему каналу ввода-вывода — вместо этого применяются какие-нибудь однозадачные MIPS-ы со FreeRTOS, сделанные по технологиям харда и софта рабочих станций начала 90-х годов. И весь «прогресс», который может сделать эмбед — это перенять более новые устаревшие технологии, например, повесить на панель китайский планшет с гугл хромом и приложухой на Electron (привет Маску) — соответственно, про надежность в этот момент уже можно просто забыть, даже уровня древних методик аля MISRA.

Как я понимаю, эмбедед – довольно инертная и консервативная среда. Пока производитель почешется запилить SDK под раст и добавить необходимые оптимизации в LLVM – может пройти много времени.

Производитель вообще не чешется, он просто делает минимальные правки к инструментам 30-летней давности. 30 лет назад раста не существовало, так что сорян, подождите до 2040-го года.

Это в какой-то отдельно взятой индустрии, где именно C и C++ нужны. В вебе это, очевидно, не так.

В вебе уязвимы сам браузер, но в браузеры вкладываются астрономические объемы ресурсов, как в то же ядро линя — именно потому ни линь, ни браузер не могут быть по-настоящему надежными и неуязвимыми, но эта надежность может быть ПРИЕМЛИМОЙ.

Я спорил с тем, что сишечка обладает особенной близостью к железу или «оптимальным уровнем абстракции».

Я не помню за весь тред никаких слов про «близость к железу» (я бы сам поспорил, потому что низкоуровневость платформонезависимого ЯП контрпродуктивна). Был разговор про «на Си пишут потому, что пишут на Си» — это совсем другое. Если бы писали на паскале, то писали бы на паскале и дальше. Или на PL/I. Причем, yax123 вроде как согласен в этом с тобой, и предъявляет только тот факт, что таки «пишут на Си».

Ничего она не приемлемая. Просто лучших альтернатив нет, приходится жрать что дают. Ну и вебовцы очень постарались чтоб их и не было - написать браузер с поддержкой всех сайтов за короткий срок нереально.