Опубликован выпуск проекта posixutils-rs 0.2.1, нацеленного на разработку на языке Rust коллекции утилит командной строки, упоминаемых в стандарте POSIX и соответствующих его требованиям (cp, mv, awk, make, vi, find, sort, wc, xargs, sh, m4, sed и т.п.). При разработке по возможности используются уже существующие crate-пакеты. Код posixutils-rs распространяется под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61908
Количество звездочек на GitHub свидетельствует о том, что это не вызывает большого интереса у пользователей.
Это всё потому что вы ставите мало лайков и не подписыватесь на канал во время пулреквеста. Алгоритмы гитхаба не продвигают проект! Все ссылки и куаркоды в описании!
нажал на колокольчик и рассказал всем в соцсетяхя даже начал ходить по квартирам с Rust Book и рассказывать людям о Rust
А как книжка называется, не "Сторожевая башня Rust"?
> А как книжка называется, не "Сторожевая башня Rust"?Да нет же, зачем мешать кирилицу с латиницей?, - "Ржавая сторожевая башня"
Так эта шляпа только опубликовалась. У uutils 17k звёзд, например.
Так мы узнали примерное количество адептов Раста с аккаунтом на GitHub.
>Количество звездочек на GitHub свидетельствует о том, что это не вызывает большого интереса у пользователей.Спасибо за напоминание, добавил звезду.
Чему именно добавили?
как там, cargo уже дотягивает до conan или хотя бы до vcpkg?
Давно превзошёл.
В раздутости разве что.
По функциональности, конечно.
Conan2 та ещё жесть. Причём первая версия была огонь: простая, легко интегрировалась куда угодно. Чего у авторов руки зачесались - не понятно. Хоть я и адепт плюсов, но эту тенденцию в комьюнити не понимаю: чем больше страдаешь, тем лучше. Это я о CMake и Conan2, которые чуть ли не негласные стандарты
Поясните, каким образом эти новости связаны? Связь в том, что оба проекта -- едва рабочая шляпа?
Нет. Подсказка находится в названии новости.
>не планирует обеспечивать совместимость с утилитами GNU, функциональность которых воспринимается авторами как необоснованно раздутая.Рекомендую авторам хотябы недельку поюзать солярку без гнутых утилит, а потом говорить о раздутой функциональности.
> Рекомендую авторам хотябы недельку поюзать солярку без гнутых утилит, а
> потом говорить о раздутой функциональности.Они видите ли будут юзать - какое нибудь putty.exe, а вон то - для других, типа кушайте их безопасный код.
>>putty.exeВообще говоря, в 10-ю венду с какого-то апдейта уже встроен клиент SSH. Это ваше пусси устарело.
>>>putty.exe
> Вообще говоря, в 10-ю венду с какого-то апдейта уже встроен клиент SSH.
> Это ваше пусси устарело.Оно уж совершенно точно не мое. Ибо нахрен это в линухе вперлось? Оно там страшное и кривое, так что его популярность в районе плинтуса.
Ну и это, когда уже ядро то на Linux заменят? Вроде уж все слагаемые на месте :). Что они, GDI на Linux Kernel портануть не могут? Пусть вайн возьмут, во!
alpine юзаю не один год.
все замечательно.
единственное достоинство гнутых утилит - меньше в конечном итоге будет пайпов, а следовательно, форков.
но оно невелируется тем, что в консоли Вы разницу во времени просто не заметите. а в скриптах, что посикс-совместимые, что не посикс-совместимы утилиты использовать - крайне сомнительно, ибо один черт все тормозить будет, за исключением ситуаций, когда Вы, например mv/cp/mkdir/etc в сабшелле пускаете; обойтись легко можно средставми даже исклюяительно посикс-шелла(в плане обработки текста), что уж говорить о ash-подобных.
А что, пусть люди тренируются. Всяко лучше, чем заниматся всякими ...
Вчера я попробовал собрать amdgpu_top, написанный на расте. Оно по зависимостям скачало адову тучу крейтов (на мелкую утилитку, ага), среди которых была пачка чего-то там для windows.Сдаётся мне, в лице растаманов мир увидит такое цунами дерьмокодинга, какого не видел даже в лице джаваскрипто- и питоноприматов.
> Оно по зависимостям скачало адову тучу крейтов (на мелкую утилитку, ага), среди которых была пачка чего-то там для windows.И запихало все в один бинарник
Adding windows v0.52.0 (latest: v0.58.0)
Если про эту строчку так это просто добавление в зависимости от winithttps://github.com/rust-windowing/winit/blob/dfea49f48850670...
Вы не не увидили фразы downloading/compiling windows
> Вчера я попробовал собрать amdgpu_top, написанный на расте. Оно по зависимостям
> скачало адову тучу крейтов (на мелкую утилитку, ага), среди которых была пачка
> чего-то там для windows.А помните, дети, какой-то академ нахваливал WinNT? А потом он его на свое горе еще и попробовал... да... :)
> Сдаётся мне, в лице растаманов мир увидит такое цунами дерьмокодинга, какого не
> видел даже в лице джаваскрипто- и питоноприматов.Надо же, фракталушка стал догадываться кто в основном ведется на хайп и во что имнено это ему отольется :)
> на мелкую утилитку, агаЭта "мелкая утилитка" на самом деле умеет довольно многое. Не находишь? Поэтому совсем не удивительно, что ей надо много чего для своей работы.
> среди которых была пачка чего-то там для windows
Слышал звон, да не знаю, где он. Windows - это всегда операционная система? Или это может быть элементом интерфейса? Утилитка, которую ты решил собрать, она в двух режимах работать умеет: текстовом и графическом. Попробуй поразмышлять над этим на досуге.
> Сдаётся мне, в лице растаманов мир увидит такое цунами дерьмокодинга, какого не видел даже в лице джаваскрипто- и питоноприматов.
Кто-то здесь говорил про токсичное Rust-сообщество. Похоже, ему есть чему поучиться в этом плане у ненавистников этого языка программирования.
> Кто-то здесь говорил про токсичное Rust-сообщество.Да они просто в своем глазу бревнище не видят.
Можно вспомнить как поливали друг друга дырящечники и плюсовики в 200х.
Как дыряшечники хаяли джаву, как хаяли питон, как обсирали с#, как... да мне сложно вспомнить хоть один язык, в обсуждение которого не врывались сишники и не начинали испражняться.
> Слышал звон, да не знаю, где он. Windows - это всегда операционная система? Или это может быть элементом интерфейса?ну я тоже только слышал звон, да и компиляцией не занимаюсь
https://github.com/Umio-Yasuno/amdgpu_top/blob/03d7c87bd66c2...
https://crates.io/crates/windows/0.52.0
Это точно элемент интерфейса?
Через этот crate можно отрисовать виндовый GUI
круто
1. таки получается, что это все таки "пачка чего-то там для windows". И оно не только для GUI
2. зачем там виндовый GUI? оно от libdrm зависит и на винде работать не может
>токсичное Rust-сообществоВсе так и есть.
>есть чему поучиться в этом плане у ненавистников этого языка программирования.
Типичное лицемерие растовщиков "а нас то за що???". Типа когда они тут токсят против другиях ЯП это норм, а их ни-ни.
Растовики косят языки (всегда называя конкретные аргументы, а не типа вот этого "синтаксис не такой"). Но речь вышла шла не о языках, всё же.
Аллилуя! Фрактал столько времени критиковавший чистый Си, и расхваливавший Раст, теперь критично отзывается о Расте! Духи открыли Фракталу глаза на реальность. Теперь, быть может он полюбит чистый Си и отвергнет Си плюс-плюс!
6% производительность вроде бы немного -- такую разницу иногда можно получить, просто сменив транслятор. Но это потеря на обёртке над оптимизированным асмом. Если в первом приближении принять, что работа обёртки занимает 10% времени, то получается новый код медленнее на 60%?
тут главный вопрос - зачем ? Ибо во-первых 20 человекомесяцев это дофига, а во-вторых - зачем это нужно, если AV1 на расте уже был и называется на 80% также "rav1e", причём ещё и находится в репозиториях "xiph", т.е. той же тусовки, что развивает ogg и пр.
Этот вопрос сложнее, чем прикинуть цифры. Если с POSIX-утилитами очевидно -- меняют лицензию и уходят от GNU, то тут теряюсь в догадках.
> тут главный вопрос - зачем ?Странный вопрос. Но еще более странная аргументация, в которой есть собственно ответы))
Вот смотри: rav1e - AV1 encoder. ENCODER.
А rav1d это что? AV1 decoder. DECODER.
Видишь как просто?А теперь попробуй осознать насколько тупо звучит твое во-вторых - "Зачем же нужен декодер, если у нас уже есть энкодер?"
А вообще можно было зайти на страницу проекта, благо ссылка есть прямо в новости, и прочитать его цели.
Основные: выкинуть сишку на мороз и при этом использовать тот же асм-код что dav1d и оставить совместимость интерфейсов.- librav1d is designed to be a drop-in replacement for libdav1d
- Move dav1d's C code to Rust for memory safety
- Reuse the assembly code from dav1d and make it easy to frequently synchronize it
А куда можно фичреквест по функционалу сайта отправить. Пора делать отдельную вкладу с названием "что сегодня переписывают и форкают"
Лично Максиму Чиркову, он же mc, ссылка на этой странице внизу справа.
Нет, не надо.
А вот бот-идоратор, ИМХО, слишком "злой". Но как говорится, каков хозяин, так и его собака лает!
Абырвалг, всем!
> Код posixutils-rs распространяется под лицензией MIT.Опять корпорациям помогают.
>> Код posixutils-rs распространяется под лицензией MIT.
> Опять неправильным корпорациям помогают.Во-во, а нужно чтоб только у Гугла, Амазона, Клаудфляра и прочих SaaS халява была. Тогда да, тогда наступит светлое гпл-будущее!!!
То ли дело линукс под жипиель, который разрабатывают корпы. Двойные стандарты - во!
Так конечно за них же никто не разработал бзд или мит версию.
Корпы разрабатывают линукс под жипиель --> корпы помогают юзерам
Растеры разрабатывают под бздёй --> растеры помогают корпам
> растеры помогают корпам...которые разрабатывают линукс под жипиэль и этим помогают юзерам
> То ли дело линукс под жипиель, который разрабатывают корпы. Двойные стандарты - во!Расскажи какие корпы dav1d делали? :). И вот GPL кстати помогает конверсии оных в тягловую силу, а не тех кто растаскивает проект по норкам.
Так dav1d как раз под BSD.
Потому что выпускать декодер под гнураком - это нужно быть ну очень особо одаренным.
Его же никто использовать не сможет, ни в одну железку не засунешь.
> Так dav1d как раз под BSD.Ну он и был ни жив ни мертв фиг знает сколько.
> Потому что выпускать декодер под гнураком - это нужно быть ну очень особо одаренным.
Ну вот именно декодер - таки, пожалуй, да.
> Его же никто использовать не сможет, ни в одну железку не засунешь.
Крутая идея - устроить халяву железячникам, получив с них - фигу. Впрочем они могут просто взять модуль HW декодера так то.
Ты наверное не в курсе, что 90% ядра пилят программисты на зарплатах в корпорациях, а не Вася Пупкин из Усть-Подпивасинска???
Они и пилят благодаря гпл. Или почему ты думаешь они фряху не пилят подумай на досуге.
> Они и пилят благодаря гпл. Или почему ты думаешь они фряху не
> пилят подумай на досуге.Вон там success story от всяких ластиков и редисок - как корпы у них нашару надергали кода, вернули фигу - все еще хотите им пермиссивную халяву устраивать? :)
Отличный пример вреда лицензий bsd и apache для своих авторов.
> Или почему ты думаешь они фряху не пилятКроме лицензий есть ещё модели разработки
Модель разработки меняется в зависимости от задач и не выбита в камне.
>Или почему ты думаешь они фряху не пилят подумай на досуге.фряху не пилят, а LLVM пилят. LLVM не маленький проект.
почему так? подумай на досуге.
> почему так? подумай на досуге.Ставлю на то, что LLVM нужен.
А фряха - нинужна))
Вот поэтому одно активно пилят, а другое гниет под забором.
Потому что на зарплате или на прикорме у Яббла. И нужно, в первую очередь, огрызку.
потому что нужно подсадить всех на подконтрольный корпорастам llvm с несвободной лицензией, после чего закрутить гайки и грести бабло лопатой
>почему ты думаешь они фряху не пилятКто сказал? MacOS X целый напилили
> rav1d
> написанный на языке Rust.Assembly 65.3%
Rust 17.1%
C 16.1%
на 17.1% безопаснее по памяти и лучше алгоритмы, чем остальные
В чем безопасТность заключается в ансейф блоках?
Ты там явно никогда не был раз так рассуждаешь.
В том, что они выделены этим самым unsafe. То есть, их сразу видно.
когда весь проект - сплошной unsafe-блок, смысла в этом маловато :)
суть их в том, чтобы пару раз заморочиться, описать условия применения, а потом в safe-коде их зафорсить. и дергать уже безопасное апи.
но в кодеке, очевидно, никто таким заниматься не будет из за требуемой скорости. следовательно, толку с раста в нем - ноль.
Недоброжелатель всегда может в ансейф блок внедрить небезопасный код. И никто этого не найдет.
Я думаю, это будет продолжаться до тех пор, пока будут внешние зависимости от библиотек на других языках. Как только и эти библиотеки перепишут, количество unsafe-блоков заметно поуменьшится. Кроме того, будет довольно просто заменять unsafe, на обычный код, потому что, как я уже выше заметил, такие блоки сразу видны, их легко искать.
что изменится?
должно быть так:
unsafe -> абстракция -> safe.
а имеем черт-те что.
и если Вы unsafe из extern'ов передвините в unsafe-блоки, это будет не более, чем перестановка кроватей.
В случае с растом можно провести аудит кода и СРАЗУ оценить риски по наличию unsafe. В с++ и с это невозможно по определению. Энтерпрайз сегмент уже давно подвинул сишников из своих масштабных проектов, набрал жаберов и получает баизнес-результат, а не черную дыру затрат на разработку и ловлю багов.
Это как жёлтая ленточка безопасности в ней нуль и всем на неё плевать.
В том, что ты новость непонятно как читаешь. Особенно сложно для тебя понять то место, где написано: "...прошлый опыт выявления уязвимостей в декодировщиках видео показывает, что проблемы в основном возникают в высокоуровневом коде разбора формата, а не в низкоуровневых операциях с данными...", а перед этим - "базовые функции декодирования примитивных значений реализованы на ассемблере в виде unsafe-блоков (задействован ассемблерный код из dav1d)". Разжую - в сейф-режиме переписано то, в чем в основном возникали проблемы. Если и сейчас не понял - проходи мимо, дорогой, здоровья тебе и попутного ветра в спину.Что-то я слишком требователен к растохейтерам. Они обычно с логикой не дружат, зато у них чувство прекрасного чрезмерно развито и спать мешает - "ужасный растовский синтаксис" в кошмарах снится.
Во-первых есть более каноничный для rav1e, который более растоманский, чем данный протест против здравого смысла с очередным переписыванием сишного софта, а во-вторых не на 17%, а на куда меньше, ибо распределение потенциальных ошибок для упомянутых языков не пропорционально доле кода, так например в ассемблере вообще могут не выделять память, а только обрабатывать, да и не очевидно какая доля работы с памятью осталась на си, а какая перетекла и стала "безопаснее" на расте.
Во-первых, rav1e - это ENCODER, тогда как rav1d - DECODER.
> Assembly 65.3%
> Rust 17.1%
> C 16.1%То ли дело
> dav1d
> написанный на языке Си.
> Assembly 79.8%
> C 19.7%
> То ли дело
>> dav1d
>> написанный на языке Си.Пруфы будут?
> Пруфы будут?Пруфы чего тебе нужны, дорогой?
Посмотри в код что ли, ну или открой какую нибудь новость о dav1d:
> Код проекта написан на языке C (C99)
>
.v_w8_loop:
vpbroadcastq xm1, [srcq+ssq*1]
lea srcq, [srcq+ssq*2]
vpblendd xm2, xm1, xm0, 0x03 ; 0 1
vpbroadcastq xm0, [srcq+ssq*0]
vpblendd xm1, xm1, xm0, 0x0c ; 1 2
punpcklbw xm3, xm1, xm2
punpckhbw xm1, xm2
pmaddubsw xm3, xm6
pmaddubsw xm1, xm6
pmulhrsw xm3, xm7
pmulhrsw xm1, xm7
packuswb xm3, xm1
movq [dstq+dsq*0], xm3
movhps [dstq+dsq*1], xm3
lea dstq, [dstq+dsq*2]
sub hd, 2
jg .v_w8_loop
RETНахера и зачем, когда это делается интринсиками?
> это делается интринсикамиДля какого компилятора и какой версии?
Скорее всего асм-код генерируют (закрытой тулзой из закрытых исходников). Щас бы нетривиальные алгоритмы писать на асме миллионами строк кода.
Это ты ещё скажи спасибо что этот асм код не из проприетари выдрали.
> RET
> Нахера и зачем, когда это делается интринсиками?Что бы помешать транслятору заинлайнить, очевидно.
зачем оно надо, если rust - не в POSIX? было б куда интереснее увидеть это все на с99.
> rust - не в POSIXЭто досадное недоразумение. Скоро исправим.
Каким образом?
Твой posix давно почил в бозе так же как и вся идеология юникс. Один только сустемд чего стоит.
> Твой posix давно почил в бозе так же как и вся идеология юникс. Один только сустемд чего стоит.POSIX как таковой ортогонален идеологиям unix и прочим systemd.
все, кому нужно написать портабельный софт, как в соответствии со стандартом писали, так и пишут. ибо альтернатив в этом поле нет.
>зачем оно надо?наверное для Redox'а это надо, чтобы была POSIX-совместимость.
хм.. ну если они прослойку сделают, то, может, оно даже жить будет.
вон, как в fuchsia
скорее для винды
То есть, они переписали их на rust не один раз, а два?
Кто они? Это две разных команды людей.
Задачка сколько раз две разных команды людей перепишут один и тот же код.
Задачка со звездочкой - во сколько раз при этом повысится безопасность.
> То есть, они переписали их на rust не один раз, а два?А сколько раз будет с учетом bsdutils, gnu coreutils, toybox, busybox, sbase?
Хотя не, это ведь си, значит другое!
А почему бы и нет? Тебе-то что?
> То есть, они переписали их на rust не один раз, а два?Да нет, побольше уже. Это как минимум третья попытка.
О предыдущих двух на опеннете уже писали, можете поискать.
>и компилятора c99Ну всё, теперь и компилятор си перепишут на расте!
А безопасно нет будет.
За пару месяцев освоил раст более или менее. Пилю на нем проект, пока написал около 5к строк всего. Очень мне нравится язык и экосистема. Недостатков в языке я особо не заметил, а вот в среде разработки они есть пока что, но не сильные. В итоге все очень нравится, свои проекты хоббийные я только на нем пилить далее буду, он прям хорошо подходит.
> 5к строк всегоНичоси "всего". Большинство любителей шлепать формочки и прочие джаваскриптеры такого за всю жизнь не пишут.
Откуда такие познания? Я просто напомню тебе, что это 5KLOC. Средний проект _начинающих_ любителей клепать формочки и джаваскриптеров в 10-20 раз больше (считая только собственный код ессно). Это буквально проект уровня привет мир. Справедливости ради, мои привет миры на расте в пределах 1000 строк. Мои сишные привет миры были на десятки тысяч строк. Ну, тут главное не задумываться о низкой эффективности разработки с растом (и последующей необходимости переписывать всё на плюсы). Некоторые утилиты вполне неплохо себя ощущают и на расте, если забыть про высокую ресрсоёмкость и странные проблемы с тулчейном. Главное тут, чтобы было приятно использовать и обновлять компоненты.
Это хело ворлд на 1000 строк? Врешь собака, код в студию!
Моя первая программа (самая первая) использовала curl с openssl, libxml2 и pcre2, висела в кроне и буквально печатала строку в лог в зависимости от ситуации. Плюс разбор аргументов, вывод сообщений и код, чтобы не падала в минимально нештатных ситуациях. Это уже тысячи строк. Ты какой-то странный.
Кстати, ознакомься с gnu hello.
Коммент дня! :D
Не уверен, что ты хотел этим сообщить, но вот то, что местные писатели операционок в последний раз видели си в школе (и то, это был какой-нибудь борланд, с реальным общего имеющий достаточно мало), вполне вероятно. Им не помешало бы освежить в памяти, что такое си, и как он выглядит.
С давным-давно морально устаревшим языком программирования Си интересно ознакамливаться разве что антропологам каким.
Вот не надо про "морально устаревший" и про антропологов. Всякому языку свое место, есть оно и у Си, и у Раста. Пусть цветут все цветы.
> Всякому языку свое местоАбсолютно верно! Напр. место на свалке истории.
Или в клубах по интересам, как это происходит с ретрожелезом или ретроавто.
Но не на миллионах серверов и миллиардах смартфонов.
Почему ж не надо? Эти языки объективно не справляются с многократно возросшей сложностью ПО. Об этом все говорят, кто сколь-либо находится в теме. Понятно, что переучиваться - это огромная когнитивная нагрузка, особенно, когда речь идёт о языке, который намного более сложный, чем тот же Си (но при этом гораздо проще Плюсов), поэтому люди и сопротивляются, как могут. Иной раз Раст может действительно привнести временные неудобства в крупный проект, как в тот же Линукс. Но, к примеру, Гугл, нашёл выход, как с этим справляться (Андроид). Не вижу причин, почему другие не могут так же.Я не хочу сказать, что у языка Раст нет недостатков. Они есть, и хорошо известны тем, кто в теме. Но, увы, на этом форуме реальных аргументов, критикующих эти недостатки, до сих пор не встречалось. Обычно всё скатывается в "плохой синтаксис", дальше этого дело не идёт.
Уважаемый Прохожий, лично по моим ощущениям Rust намного превосходит по сложности C++ и другие языки. Проблемы же с Си возникают практически только в больших проектах, где невозможно удержать все в голове. Когда кода не очень много и когда его изначально пишут с упором на безопасность результат получается очень хорошим. Поэтому я уверен, что чистый Си был, есть и будет в тех областях, где нужно относительно немного очень быстрого и компактного кода.Что касается Rust - лично у меня к самому языку есть претензия только в очень неудачном, на мой взгляд, синтаксисе указания времени жизни. А вот к его стандартной библиотеке претензий накопилось уже довольно много. Наверное это происходит потому, что в отличии от большинства хаящих Rust икспердов с OpenNET, я на нем время от времени реально что-то пишу :) Чтобы не быть голословным, приведу одну из них. У BufReader есть метод lines(), который позволяет удобно проводить итерацию по строкам. И все бы ничего, но если в одной из строк попадется не UTF8 байты (а в реальном мире они туда обязательно попадут, причем, возможно, целенаправленно), вся считанная строка, фигурально говоря, превращается в тыкву. И я так и не нашел возможности получить в обработчике ошибок доступ к ее байтовому слайсу. Т.е. этот очень удобный метод, по факту, оказывается непригодным к использованию в реальных программах, запускаемых в недружественном программном окружении.
> Что касается Rust - лично у меня к самому языку есть претензия только в очень неудачном, на мой взгляд, синтаксисе указания времени жизни.А что насчёт возможных вариантов условной компиляции? Которая просто необходимо для проектов, живущих десятки лет.
Причем обычно уже никто на знает как работает часть кода. Просто не трогают, обкладывая ifdef'ами.
Посмотрите на реализацию QTermWidget. Там часть кода выдрана из реализаций для систем прошлого тысячилетия.
> Уважаемый Прохожий, лично по моим ощущениям Rust намного превосходит по сложности C++ и другие языки.Не, как писать программы на C++ я так и не смог понять. Сколько я не читал литературы и C++ кода, я не понял как это делать. Я так и не понял, к чему там наследование, тем более множественное например. В каких случаях его уместно использовать? Темплиты -- это же ужос, это макроподстановки, а с макроподстановками единственный разумный способ работы -- избегать их всеми способами, потому что когда с ними пойдёт что-то не так, время на разгребание получившегося хаоса превзойдёт время необходимое на то, чтобы копипастом и прочими средствами текстового редактора сделать то же самое, что делается макросами.
Раст же я освоил легко и непринуждённо. Были проблемы с тем, что некоторые привычные паттерны программирования там не работают, но эта проблема решалась через нахождение альтернативных паттернов.
> Т.е. этот очень удобный метод, по факту, оказывается непригодным к использованию в реальных программах, запускаемых в недружественном программном окружении.
В недружественном окружении, если ты получаешь кривой ввод, ты отбрасываешь все уже прочитанные данные, выкидываешь ошибку, и закрываешь файловый дескриптор. Не, ну ты вдумайся, что ты ещё ты моешь сделать с этим кривым вводом, если в нём вместо utf8 ты находишь произвольные байты?
И если у тебя есть какая-то разумная стратегия? Вот бери и реализуй эту стратегию. Реализовать свой BufRead не так уж и сложно, и совсем тривиально можно сделать обёртку поверх BufRead. Но я б рекомендовал поискать по crates.io, вероятно там есть что-нибудь типа bufread, но чтобы кодировку менять на ходу. Это для того же http(s) может быть полезно, потому что начинаешь ты его читать как поток ascii, но впоследствии ты вероятно захочешь читать utf8. А если ты ещё и браузер, который унижаться перед серверами и проглатывать абсолютно любые ошибки, то вероятно тебе захочется читать байты, и потом lossy способом перегонять в utf8. Но это позорная старпёрская стратегия, призывающая быть толерантным к нарушениям протоколов со стороны других. Толерантность здесь неуместна, если на том конце программисты не могут реализовать протокол, то пускай идут дворниками работать. Из-за этой дедовской стратегии мы и оказались в сегодняшней ситуации, когда даже для того, чтобы email-адрес распарсить, надо потратить неделю чтения документации и статей описывающих чужой опыт такого парсинга. И эта никому не нужная сложность -- стабильный источник багов и даже зияющих дыр в программах, которые вместо того, чтобы столкнувшись с отклонением от протокола, закрыть файловый дескриптор, начинают плясать с бубном вокруг этого файлового дескриптора и наступают на какие-нибудь грабли.
Есть один хороший принцип доставшийся нам от дедов: KISS. Не надо усложнять программу, если нет горящей необходимости её усложнять. До тех пор, пока программа работает без плясок с бубном вокруг не-utf8 ввода, не надо усложнять её до способности работать с не-utf8 вводом. Не надо пытаться своей программой решить все проблемы всего огромного мира. Более того, надо усердно обрыкиваться от попыток других навязать тебе их проблемы и убедить тебя в том, что это твои проблемы. Это им же на пользу пойдёт.
Я тут могу привести вполне реальный пример. uutils вваливаются в панику, столкнувшись с не-utf8 именем файла. И благодаря им я нашёл в своём хомяке файлы с koi8-r именами, которые каким-то образом остались откуда-то из +-2005 года, когда я конвертал все имена из koi8-r в utf8. Результат? Я сделал то, что ленился сделать 15 лет: я нашёл все несконвертированные имена, и перекодировал их.
> В недружественном окружении, если ты получаешь кривой ввод, ты отбрасываешь все уже прочитанные данные, выкидываешь ошибку, и закрываешь файловый дескриптор. Не, ну ты вдумайся, что ты ещё ты моешь сделать с этим кривым вводом, если в нём вместо utf8 ты находишь произвольные байты?Кривые байты целенаправленно попадают, например, в прямые логи, которые надо проанализировать. Закрывать лог из-за того, что кто-то целенаправленно внес туда "мину" - это плохая стратегия поведения для анализирующей этот лог программы. Даже просто пропуск строчки, как это легко можно сделать с lines(), является плохой идеей. Кривой ввод нужно сохранить для возможности дальнейшего анализа.
Обходные методы этого всего есть, но обидно то, что авторы стандартной библиотеки сразу не сделали по человечески.
А ещё интереснее смотреть на собачек Павлова от программирования :) Оне тяффкают! :)
> А ещё интереснее смотреть на собачек Павлова от программирования :) Оне тяффкают!Хм.. ну так не тяфкай)
Никто же тебя не заставляет.
(Если тебя взяли в плен и пытают - моргни 2 раза)
> Справедливости ради, мои привет миры на расте в пределах 1000 строк.Лет 20 назад я операционку свою писал на Си и она уместилась в чуть менее 300 строк. Могла в менеджмент памяти и даже tcp ip. Что ты там такого нaгoвнoкoдил на 1000 строк?
Это как раз дело не хитрое. А ты вот пробовал писать корректный код? Или там хотя бы конкатенировать строки.
А у меня все программы уместились в одну строку! Правда она довольно длинная...
> Это буквально проект уровня привет мир.Эту оценку, конечно, нельзя назвать сколь-либо объективной. Потому что кроме собственных 5 тыс. строк может быть задействовано библиотек на 100 тыс. строк. И это уже очень далеко от проекта уровня "Привет, мир".
>он прям хорошо подходита для чего он хорошо подходит, если не секрет?
Да, в общем, для всего практически, кроме узкоспециализированных областей, конечно (типа запросов к реляционным базам данных, например). Это язык программирования универсального назначения.
У меня два хоббийных проекта. 1. Это один децентрализованный веб сервис. 2. Это транслятор одного вида специализированных текстов в другой.
Достаточно серьёзные программы
снимите себе номер
>Проект сосредоточен главным образом на достижении соответствия требованиям спецификации POSIX.2024 и не планирует обеспечивать совместимость с утилитами GNUЯсно понятно. Враги Свободы.
Тьфу, даже переписать нормально не могут. Казалось бы держи-обводи, слабо связанный код, но нет. Никуда не годится, позор.
Свобода это отсутствие лицензии вообще. В остальном это не свобода, но ТЕ или ИНЫЕ ограничения.
Свобода противоречивое слово.
Не, если лицензии нет, то код вообще использовать нельзя.
Копилефт ограничивает самоупроавство и произвол проприетарщиков и прочих копирастов. Это означает свободу для простыч программистов и пользователей.
> Копилефт ограничивает самоупроавство и произвол проприетарщиков и прочих копирастов.Да, то-то же оно ограничило самоуправство всяких Гуглов, Амазонов и прочих SaaS провайдеров.
"облачные провайдеры создают производные коммерческие продукты и занимаются перепродаже в виде облачных сервисов, но не принимают участия в жизни сообщества и не помогают в разработке."> Это означает свободу для простыч программистов и пользователей.
Мы же говорим про ЖоПЛь рак который запрещает программисту зарабатывать на продаже кода?
Мозолеед в своем манифесте отлично показал свое отношение к программистам, предложениями запретить высокие зарплаты и отправить разработчиков ходить с протянутой рукой.
ИЧСХ украсть емакс и продать, ему это не помешало.
GPL не запрещает программисту зарабатывать на продаже СВОЕГО кода.
GPL запрещает программисту зарабатывать на продаже ЧУЖОГО кода.
>Свобода это отсутствие лицензии вообще.Нет, если лицензии нет то по закону вроде все права принадлежат написавшему код. То есть его нельзя использовать никак, только смотреть. Для свободы есть передача в общественное достояние (public domain), но оно существует не везде, поэтому есть всякие лицензии типа CC0 или Unlicense: https://en.wikipedia.org/wiki/Public_domain_equivalent_license
> реализованы на ассемблере в виде unsafe-блоков
> (задействован ассемблерный код из dav1d)Вот такое вот хреновое лето^W Rust :D
Спам и DDoS - это превышение полномочий (abuse). Предлагаю перевод всего и вся на rust расмстаривать как аналогичное действие.
Со всеми этими нейросетями могли бы просто сразу переписать в машинные коды. Зачем посредник в лице яп?
сразу в машинные коды любой компилятор может, а вот на раст - тут думать надо
Тогда ЗП получит тоже нейросеть.
Опять новость, что на расте что-то ПЕРЕписывают давно и успешно работающее.Это симптомчик, потому что, как по мне, у нормального программиста есть куча идей что свое новое написать. Но видимо с нуля кодить на расте слишком сложно...
> Опять новость, что на расте что-то ПЕРЕписывают давно и успешно работающее.
> Это симптомчик, потому что, как по мне, у нормального программиста есть куча
> идей что свое новое написать. Но видимо с нуля кодить на
> сишке слишком сложно...Ты сейчас о чем конкретно, о гнутых корутилитах, базибоксе, тойбоксе или о сибейзе? Туда тоже уже растоманы добрались? 8-O
Дело не только в этом. Примеры чего-то сложного написанные на расти 10 лет назад сейчас уже не компилятся, и поди ещё там разбери без пол литра что в куске безсмысленного врапа там не нравится новому компилюсу. Я лично не особо по алкахе, наверно по этой причине и забросил адаптироваиь
"Зато нет UB" говорили они.
Потому что если нет стандарта, то нет и UB.
Это проблема тех, кто постит новости, а не раста. Например, про Nushell я на опеннете вообще ниразу не видел, а это - самый крутой шелл и язык программирования на замену баша и его выпускают уже несколько лет.
> Например, про Nushell я на опеннете вообще ниразу не видел,А это https://www.opennet.dev/51375-shell что?
Один раз 5 лет назад? О чём и речь. Зато про переписывание каких-то утилит постоянно сообщают.
Разве они уже не переписаны на zig?
Ну допустим, и что?
>Дополнительно можно отметить анонс проекта rav1d, развивающего высокопроизводительный декодировщик формата кодирования видео AV1, написанный на языке Rust. Разработка ведётся через портирование на Rust кода декодировщика библиотеки dav1d, отличающейся высокой производительностьюОтлично, как допишут - можно будет обратно на си переписать. Будет безопасно: всё проверено растовым borrow-checkerом.
> Отлично, как допишут - можно будет обратно на си переписать. Будет безопасно:
> всё проверено растовым borrow-checkerом.Сиплюсплюсеры в соседней новости уже о чем-то догадываются :)
> Отлично, как допишут - можно будет обратно на си переписать. Будет безопасно: всё проверено растовым borrow-checkerом.Было бы интересно посмотреть.
И посчитать сколько CVE средний сишник модет сделать, при переписывании готового кода)
Ну посмотри если интересно
Интересно, сколько при этом исправит, ведь CVE это не только ошибки памяти и гарантий от них Раст не дает. https://github.com/Speykious/cve-rs
интересная фраза - "проблемы в основном возникают в высокоуровневом коде разбора формата, а не в низкоуровневых операциях с данными". Получается, что низкоуровневые язык ассемблера и С гораздо надёжнее высокоуровневых языков?
>язык ассемблера и СТоже высокоуровневые. Это всего лишь означает, что проблемы в основном возникают в высокоуровневом коде разбора формата, а не в низкоуровневых операциях с данными.
Просто в низкоуровневом коде проблем никто найти не смог.
> Тоже высокоуровневые.Только C.
Макроассемблеры довольно высокоуровневые. Но и современные наборы инструкций процессоров тоже, сложно сравнивать с программированием, как оно выглядело раньше.
> Получается, что низкоуровневые язык ассемблера и С гораздо надёжнее высокоуровневых языков?Нет. Просто намного реже ошибка совершается в функции "перемножить две матрицы", чем в "пришел пакет хз откуда, давайте его парсить не проверяя входные параметры".
Хотя сишники даже сплит строки умудряются с CVE сделать.
От квалификации зависит. Понятие надёжность слишком расплывчатое.
Не всё зависит от квалификации. Часто надёжность зависит от используемых инструментов, потому что человеческий мозг не может не ошибаться, каким бы квалифицированным не был его носитель.
Инструмент никогда не может гарантировать безопасность. Это как безопасная бензопила, концептуальна невозможна.
Но может ее существенно улучшить.
Например в упомянутой бензопиле есть кнопка-стопор, которую нужно выжимать, чтобы она работала.
Отпустил - сработал цепной тормоз.
Плюс вторая рукоятка, которая тормозит пилу при обратном ударе.И это еще не все!
Для работы нужны щиток и наушники, а если дело происходит в местах, где человеческая жизнь ценится - то еще и специальные защитные костюмы от порезов (EN 381 или аналог).
Но такое конечно только для профи.
Можно и маникюр в бронекостюме делать, а то вдруг пилочкой уколешся.
Если палочка отравлена смертельным ядом - вполне разумно. Хотя речь не о маникюре в таком случае будет идти, разумеется.
> а то вдруг пилочкой уколешся.Разумеется)) А еще можно требовать нормальной стерилизации инструментов. Кто ценит свое здоровье и свою жизнь.
Не всем же нравится делать маникюр или тату в какой-то рыгаловке, где инструмент в лучшем случаем помоют под краном после предыдущего клиента. Ну а ты можешь продолжать))
> От квалификации зависит.Не только. Инструмент тоже решает.
Вот в ядре линукс есть некий Theodore Ts'o, который лабает ext4. Пишет линукс с 90х. Просто море опыта у кадра.И что? В 2013 году он закоммитил вот такую портянку github.com/torvalds/linux/commit/dc6982ff4db1f47da73b1967ef5302d6721e5b95.
Через 9 лет (2022 год) тысячи глаз наконец-то рассмотрели там уязвимость CVE-2022-1184.
Которую смогли исправить только со второй попытки.> Понятие надёжность слишком расплывчатое.
Разумеется. Но назвать кучу повторяющих из года в год однотипных дыреней нельзя назвать надежность ни в какой ситуации))
> Через 9 лет (2022 год) тысячи глаз наконец-то рассмотрели там уязвимость CVE-2022-1184.Зачем ты с этим CVE везде носишься?
Там был код, который рассчитывал на правильные данные в описании каталога. Если данные повреждались где либо на стороне, то могли перезаписаться другие блоки и потом было двойное освобождение.
Добавили проверку на правильность данных перед добавлением новых блоков.
К чему ты это привел? В расте нельзя считать данные с файла и не проверить их достоверность?
> К чему ты это привел?Это прекрасный пример отличной квалификации ядрописак и шикарных инструментов. Просто близкий к эталону.
Таких примеров конечно море, но именно Тсэ один из тех, кто копротивляется внедрению раста и заявил "вы не заставите учить раст".
Хотя он шикарный сишник и какой-то анон кидал список его CVE за последние пару лет.
И там типичные сишные дырени - use-after-free, выход за границы буфера, double free, переполнение.> В расте нельзя считать данные с файла и не проверить их достоверность?
Разумеется можно. А вот что будет дальше - вопрос))
Вот будет ли use-after-free, а?
>> К чему ты это привел?
> Это прекрасный пример отличной квалификации ядрописак и шикарных инструментов. Просто
> близкий к эталону.
> Таких примеров конечно море, но именно Тсэ один из тех, кто копротивляется
> внедрению раста и заявил "вы не заставите учить раст".
> Хотя он шикарный сишник и какой-то анон кидал список его CVE за
> последние пару лет.
> И там типичные сишные дырени - use-after-free, выход за границы буфера, double
> free, переполнение.И таки да. Он является отличным примером. Его слушают и слышат. В отличии от тебя.
>> В расте нельзя считать данные с файла и не проверить их достоверность?
> Разумеется можно. А вот что будет дальше - вопрос))
> Вот будет ли use-after-free, а?В расте можно хранить данные и и макроданные описывающие эти данные отдельно? В разных коллекциях?
Что произойдет, когда макроданные будут показывать одно а данные будут другими? Паника?
И чем паника в ядре лучше use-after-free?
> Что произойдет, когда макроданные будут показывать одно а данные будут другими? Паника?
> И чем паника в ядре лучше use-after-free?Тем что у тебя просто упадет ядро.
И это будет видно! И ты увидишь трейс и возможно починишь.
А не "у нас тут 10 лет жил бекдор, с получением рута.. всем конечно было плевать".Явная проблема всегда лучше, чем неявная.
> Явная проблема всегда лучше, чем неявная.А чего она вдруг явная?
Для ее срабатывания надо заранее сформировать файловую системы с кривыми данными.
Кто и когда это сделает?
> Он является отличным примеромНеобучаемого и не хотящего учиться?
Который годами повторяет одни и те же ошибки?
И в состоянии только давить авторитетом?
Да, он отличный пример)) Именно поэтому его и привел.> Его слушают и слышат.
А это мы еще посмотрим, т.к. история пока не закончилась.
Сейчас придет лесник и поставит на место зарвавшегося дида.
Незаменимых людей нет.> И чем паника в ядре лучше use-after-free?
Там выше уже ответили, но и я повторюсь.
Чтобы не заметить панику нужно очень-очень постараться. Это будет явная проблема.
Более того, в логе должно будет указано что и где запаниковало.
А так у вас уязвимости живут годами (вот эта - 9 лет) и никто ничего не видел))
> Необучаемого и не хотящего учиться?Поэтому он и разработал файловые системы?
> Который годами повторяет одни и те же ошибки?
А те кто на расте пишут делают каждый раз разные?
> И в состоянии только давить авторитетом?
А вот это только ваше вранье. Он в состоянии разрабатывать, в отличии от.
> Да, он отличный пример)) Именно поэтому его и привел.
И только делает ему рекламу.
Ибо ваша некомпетентность великолепный пример того, с чем он борется.> Чтобы не заметить панику нужно очень-очень постараться. Это будет явная проблема.
> Более того, в логе должно будет указано что и где запаниковало.
> А так у вас уязвимости живут годами (вот эта - 9 лет) и никто ничего не видел))Не будет лога. Файловая система отвалится.
Да и будет это где и когда захочет атакующий.
> А те кто на расте пишут делают каждый раз разные?Обычно да, потому чаще всего это логические ошибки.
Но сейчас, к сожалению, еще не изобрели простого способа верификации кода.
Как только это сделают - раст можно и нужно будет закапывать, т.к. новый язык будет на голову его выше.> А вот это только ваше вранье. Он в состоянии разрабатывать, в отличии от.
Угу, и мы видим его послужной список CVE.
> Ибо ваша некомпетентность великолепный пример того, с чем он борется.
А он с чем-то борется? Ну, кроме теплого местечка.
Он за все эти годы не в состоянии перестать делать ошибки с памятью)
Отличная реклама!> Не будет лога. Файловая система отвалится.
Да ну)) А у вас всегда одна единственная ФС? Да неужели?) Или несколько? И она волшебнейшим образом совпала с той, куда пишутся логи? Вот вы так можете это гарантировать?
> Обычно да, потому чаще всего это логические ошибки.Шедевр. Каждый раз разные ошибки. Вы столько не придумаете.
Некомпетентность во всей красе.> Угу, и мы видим его послужной список CVE.
Ничего не значащий побочный эффект реального послужного списка.
Как пример. Для разработки фс важно что бы она заработала. Искать и ликвидировать CVE можно уже после.
Неработающая фс без CVE никому не нужна.
> А он с чем-то борется? Ну, кроме теплого местечка.
С религиозными фанатиками. Условную ограниченную безопасность ставят выше работоспособности.
> Он за все эти годы не в состоянии перестать делать ошибки с памятью)
> Отличная реклама!Именно. Ибо фанатики ищущие проблему так где ее нет - прекрасная иллюстрация проблемы религиозного фанатизма.
> Да ну)) А у вас всегда одна единственная ФС? Да неужели?) Или несколько? И она волшебнейшим образом совпала с той, куда пишутся логи? Вот вы так можете это гарантировать?
Какие логи при панике? Стеки поломаны. Попытка записать что-либо может привести к порче еще сохранившихся данных.
Вы вообще хоть один драйвер в жизни отлаживали?
> В настоящее время 55 развиваемых проектом утилит соответствуют POSIX и находятся на стадии покрытия тестами, в 22 утилитах обеспечена необходимая функциональность (но пока не реализовано покрытие тестами), 20 находятся на стадии чернового варианта, а работа над 44 утилитами ещё не начата.И эти люди в ядро лезут...
> И эти люди в ядро лезут...̶Н̶у̶р̶г̶а̶л̶и̶е̶в̶ Торвальдс разрешил (с)
И вообще, разве кого-то нужно спрашивать куда можна лезть или нет?
Ядро это помойка, в которой даже базовый менеджмент памяти без ошибок сделать не смогли.
Бедный Линус в прошлом интервью жаловался.
> Ядро это помойка, в которой даже базовый менеджмент памяти без ошибок сделать
> не смогли.
> Бедный Линус в прошлом интервью жаловался.Вопрос остается. Ну и зачем тогда лезть туда?) Взяли бы да рядом сделали как надо. Но видимо есть нюанс...
так делают ведь.
вон, есть монолитная kerla.
очень даже ничего, как по мне. проект развивается, заинтересованные есть.
если б мне были интересны ядрописание с растом, скорее всего, тоже б туда пошла.
хотя, черт его знает, как они код там пишут, прошлась только беглым взглядом.
> Вопрос остается. Ну и зачем тогда лезть туда?)Может людям не нравится когда намусарено и нарыгано, вот они решили убраться.
Ядро же в куче мест используется, значит надо его сделать лучше.
Я понимаю что есть индивиды которым жить в овне и сраче нормально, но не все люди такие.> Взяли бы да рядом сделали как надо. Но видимо есть нюанс...
Так деляют.
Вот тут чел в одиночку пилит ядро opennet.ru/opennews/art.shtml?num=60391
И результат, как для одиночки, весьма достойный "реализован 31% (135 из 437) системных вызовов Linux, чего достаточно для загрузки консольного окружения на базе bash и стандартной Си-библиотеки Musl".И редокс тоже пилится, причем у него просто тонна своих низкоуроневых и не очень штук.
Свой бутлоадер, relibc, init (а линуксятникам кормят системмд с лопаты),
свои binutils, uutils и еще куча других низкоуровневых вещей.
А еще графический тулкит и оболочка на нем, шелл, пакетный менеджер, сетевой стек, аудио...Но запретить приходить и улучшать ядро вы никак не можете.
Так что продолжайте копротивляться и ныть))
>> Вопрос остается. Ну и зачем тогда лезть туда?)
> Может людям не нравится когда намусарено и нарыгано, вот они решили убраться.Сильные утверждения. Но проверять я их, конечно, не буду (с).
>> Взяли бы да рядом сделали как надо. Но видимо есть нюанс...
> Так деляют.
> Вот тут чел в одиночку пилит ядро opennet.ru/opennews/art.shtml?num=60391
> И результат, как для одиночки, весьма достойный "реализован 31% (135 из 437)
> системных вызовов Linux, чего достаточно для загрузки консольного окружения на базе
> bash и стандартной Си-библиотеки Musl".Ну Дрю Деволт тоже ядро написал на hare и дальше что? Какое отношение эти огрызки имеют к рабочему ядру?
> И редокс тоже пилится, причем у него просто тонна своих низкоуроневых и
> не очень штук.
> Свой бутлоадер, relibc, init (а линуксятникам кормят системмд с лопаты),
> свои binutils, uutils и еще куча других низкоуровневых вещей.
> А еще графический тулкит и оболочка на нем, шелл, пакетный менеджер, сетевой
> стек, аудио...Пишешь из под редокса? Пользуешься чем-то из перечисленного. Сомневаюсь.
> Но запретить приходить и улучшать ядро вы никак не можете.
> Так что продолжайте копротивляться и ныть))По твоей манере речи видно, что ты привык сидеть на всем готовом и жаловаться. И судя по комментариями - это типичные фанбои раста.
>Но видимо есть нюанс...нюанс в том, что платиновые, золотые и прочие спонсоры линукс фундейшон уже потратились на сотни миллионов денег и не желают тратится вновь. Поэтому они продолжат внедрять в ядро тот функционал, какой им надо, невзирая на всхлипывания всяких непонятных экспертов.
>>Но видимо есть нюанс...
> нюанс в том, что платиновые, золотые и прочие спонсоры линукс фундейшон уже
> потратились на сотни миллионов денег и не желают тратится вновь. Поэтому
> они продолжат внедрять в ядро тот функционал, какой им надо, невзирая
> на всхлипывания всяких непонятных экспертов.То есть большинство разработичков ядра (которые против внедрения раста) - это кучка "непонятных экспертов"?
> большинство разработичков ядра
> большинствоПруфы будут? Или ты как обычно?
>> большинство разработичков ядра
>> большинство
> Пруфы будут? Или ты как обычно?Я понимаю, что тебе как эксперту больно признавать свою неправоту, но стоит хотя бы почитать рассылку, а не жить одними желтыми новостями.
> Я понимаю, что тебе как эксперту больно признавать свою неправоту, но стоит
> хотя бы почитать рассылку, а не жить одними желтыми новостями.Т.е ссылки на рассылку где "большинство разработичков ядра против внедрения раста" не будет?
Как же так! Чего ты так позорно сливаешься?Да и по поводу большинства. Это то самое большинство которое не хотело видеть системмд?))
В ядре демократии нету, диктатор скажет - так и будет.
>> Я понимаю, что тебе как эксперту больно признавать свою неправоту, но стоит
>> хотя бы почитать рассылку, а не жить одними желтыми новостями.
> Т.е ссылки на рассылку где "большинство разработичков ядра против внедрения раста" не
> будет?
> Как же так! Чего ты так позорно сливаешься?Просто хочу чтобы ты поработал маленько. Как накидывать без пруфов вы первые. В эту игру можно играть вдвоем оказывается.
> Да и по поводу большинства. Это то самое большинство которое не хотело
> видеть системмд?))
> В ядре демократии нету, диктатор скажет - так и будет.Как скажешь. Можешь нарисовать на трусиках у себя еще один крестик за победу в комментариях.
Они тоже оценили pest, я вижу, bc и awk на нём. И прально, лучший генератор парсеров. Меня чёт понесло последнее время в написание интерпретаторов, и pest это что-то.
> Они тоже оценили pest, я вижу, bc и awk на нём. И
> прально, лучший генератор парсеров. Меня чёт понесло последнее время в написание
> интерпретаторов, и pest это что-то.Как вы яхту назовете... название больно уж говорящее, не обижайтесь когда дустом спрыснут :))
Некоторым нравится оригинальничать и переизобретать велосипеды из уже хорошо работающих вещей.
Что ты называешь "хорошо работающими вещами"? Скажи, пожалуйста, что ты имеешь в виду flex/bison, чтобы я мог над тобой поглумиться.
Подобные проекты и испортили репутацию языка...
Репутацию конкретно этого языка портит его сообщество. Оно настолько таксичное, что подобное поведение некоторых товарищей среди апологетов других языков ещё нужно поискать.
Причём здесь сообщество или отдельные его представители? Заслуга языка не в сообществе, а в его возможностях.
> Заслуга языка не в сообществе, а в его возможностях.Если ты один пишешь для себя то может и так. Но любой тот кто пишет что-то более серьезное хеллоуврота с тобой не согласится.
Гм. Амазон, Гугл, Клаудфлэр пишут что-то боолее серьёзное. И что-то не слышал от них, чтобы они чем-то были недовольны. Дашь ссылку на их недовольство на этот счёт?
Ничего серьёзного там не написано только раздутый фанатиками хайп.
Дай определение слову "серьёзный". Например, в моём понимании, прокси-сервер, которым ежедневно пользуются сотни миллионов людей по всему миру - вполне себе серьёзный софт. Или ОС, которая установлена на примерно миллиарде смартфонов (на самом деле, пока цифра намного меньше, но через несколько лет порядок будет примерно таким).
> Ничего серьёзного там не написано только раздутый фанатиками хайп.Этот эксперт в каждой новости про раст упоминает эти конторки.
>> Ничего серьёзного там не написано только раздутый фанатиками хайп.
> Этот эксперт в каждой новости про раст упоминает эти конторки.Щито поделаешь десу (с) ¯\_(ツ)_/¯
Если Воины супротив Раста в каждой теме говорят "на нем ничего не написано!111", то приходится спускаться до их уровня и тыкать мордочкой в конкретные примеры.Нравится тебе или нет, тот же cloudflare никуда не исчезнет)
> То-то на расте за 14 летО! очередной свидетель 14 лет.
Учитывая что раст 1.0 вышел в 2015, а сейчас 2024.. То у тебя с математикой примерно как и с другими областями знаний.> все вокруг уже переписали без глюков и падений. Хотя подождите те ка, что тут у нас в новости
Конечно нет.
Язык в ядро приняли вот-вот.
Копротивление дидов еще даже не достигло своего экстремума.
(я предполагаю что это будет через год-два)> Это другое надо понимать?
Да, прикинь. У них где-то написано "вот готовый проект?"
Или твое скудоумие не позволяет понять даже такие простые вещи?А вот драйвер от Асаши - это уже готовый проект.
Он прошел сертификацию Кроноса и даже получил личную благодарку от Торвальдса.Я понимаю что дыряшники любят вываливать полуфа/b/рикаты и назвать это готовым, но не все же такие.
Строгости ради, эти конторы поднялись не на расте. Да и на чем там только не пишут. И ведроид далеко не на расте написан. Ни гугл движок ни прочее
> Строгости ради, эти конторы поднялись не на расте.Эм... разумеется, они все старше раста.
Но почему-то они признали его пригодным для себя.> Да и на чем там только не пишут.
Тоже верно. Вот гугл целый Го придумал
> И ведроид далеко не на расте написан.
Но тем не менее новый код они пишут в том числе на расте, а также активно переписывают старый (в основном с си)
Я думаю там всё эволюционно, они пробуют всё подряд а потом смотрят - покатило не покатило. Когда есть ресурс можно и на расте паписать и на ерланге или вообще отправить на свалку с десяток проектов написанных на любых брейнфаках, которые всегда появляются и исчезают.
Ну написали они что-то на расте, ну работает, ну и на здоровье.В принципе, не суть важно, главное дизайн хороший намутить
> Репутацию конкретно этого языка портит его сообщество. Оно настолько таксичное, что подобное поведение некоторых товарищей среди апологетов других языков ещё нужно поискать.А можно примеры?
Пока я вижу как адепты и писаки дыряшки и плюсов ноют, что "на раст переписывают".
Да какое вам дело? Каждый может писать на том языке, на котором пожелает.
> испортили репутацию языкаЕё, репутации, никогда и не было в головах многих, присутствующих здесь "экспертов". Потому что язык они осилить не смогли (или вообще даже не начинали). Поэтому по привычке списали всё на плохой синтаксис, хотя на самом деле проблема в них самих.
А так, если говорить о мире, то до сих пор Rust - один из самых любимых языков на том же StackOverflow, судя по последнему опросу. То есть, его репутация в мире по-прежнему высока, кто бы что здесь не утверждал.
> Rust - один из самых любимых языков на том же StackOverflowРжака :) Детишки, вам уж за 25 небось, а своих мозгов всё ещё нет :) Взрослейте!
Ну и как говорят сами SoF - 'есть "любимые" языки, а есть языки на которых и в правду пишут...' (С) :-р
> Ну и как говорят сами SoF - 'есть "любимые" языки, а есть языки на которых и в правду пишут...' (С) :-рСрочно беги к гуглу, рассказывай что они з̶а̶б̶ы̶л̶и̶ ̶п̶р̶о̶ ̶к̶о̶с̶м̶и̶ч̶е̶с̶к̶у̶ю̶ ̶р̶а̶д̶и̶а̶ц̶и̶ю̶ совершиаю непоправимую ошибку!
И к редхату с нвидией и драйвером Nova.
В обьщем настало время тебе показать свою кекспертность!
Мне уже за 50. Так, к слову. И я давно уже своей головой думаю, хотя, бывает, к чужому мнению тоже прислушиваюсь, особенно, когда умные и компетентные (на мой взгляд) люди говорят о чём-то, что мне интересно. Часто полезно слушать и чужое мнение тоже. Расширяет кругозор. Так, к слову, раз уж тут пошёл обмен жизненным опытом.Тут аноним выше позволил себе усомниться в репутации. Я всего лишь опроверг его мнение, сославшись на проведенный опрос. Этот опрос, по любым меркам, куда более объективный показатель репутации, нежели мнение одного человека. Не думаешь?
Если же взглянуть на результаты опроса (судя по всему, ты их явно не видел, хотя мог бы, просто чтобы убедиться, что я не лгу), то выяснится, что этом языке и пишут уже довольно интенсивно. Не так много, как на Джаваскрипт, конечно, но это потому только, что ниша у Rust пока (?) уже.
>Rust - один из самых любимых языков на том же StackOverflowТак мы узнали, что StackOverflow не умеет боротся с накрутками.
Ладно, популярность политика накручивать, или какой-нибудь певички. Но языка программирования?!
Берём библиотеку на C/C++, пишем на Rust unsafe вставку на Asm, Asm код вызывает функции из этой библиотеки :)Эта новость прям доказательство того, что Rust - говно. Вот что нейросети смогут делать в ближайшем будущем так это проверять весь код и полностью на все возможные дыры в безопасности и Rust умрёт. А современный код на C++ и так уже безопасный, и быстрый в отличии от Rust.
> Вот что нейросети смогут делать в ближайшем будущем так это проверять весь код и полностью на все возможные дыры в безопасности и Rust умрётНу только алгоритм борова прост, а что там будет у нейросети вопрос. Можно ли ей доверять в вопросах безопасности?
кстати, аноним, вон, выше написал про нейронки.
а ведь действительно, если подумать, то кучу вещей в С проверить можно статически. я вот недавно столкнулось с некорректным поведением при сборке с -О3 на кланге(в gcc окей все было).
дело было в выходе за пределы массива. только функция не сегфолтилась, а возвращала 3.
чатгпт помог, кинула код, сказала, что черт-те что происходит и он сказал вместо <=, влепить <.
и если так задумать - нет ведь сложного ничего делать это оффлайн.
условно, в качестве процедуры тестирования, собираешь парой уомпиляторов с -О{1..3}, запускаешь тесты и если что-то не то - показываешь анализатору, который нащупает у тебя, например, выход за пределы массива(в моем случае это легко было, ибо просто не та проверка в while(). если происхождение аргумента неизвестно - то просто юзеру ткнуть туды) и там уж починить.
или, еще проще: -fsanitize=undefined в компиляторах, поддерживающих это + тесты.
я сейчас оба варианта и использую, но с нейронкой, ибо пока такого магического анализатора не подвезли.
можно сказать "а зачем все это, если rust?", но ведь:
1. С99 в POSIX
2. раст ничего предложить кроме паники в UB не может. а паниковать не проблема и в С, да еще и код мой работать везде будет.
более того, с -fsanitize=undefined, gcc точно так же сует везде проверок. поэтому для обеспечения определенного поведения, в целом, достаточно обычного юнит-тестирования всвязке со сборкой парой компиляторов.мне вот писал кто-то здесь не так давно про UB в С и то шо задетектить нереально, приводя в качестве примера переполнение signed номеров.
но, честно сказать, так и не дошло, на кой их пользовать где-то за пределами четко известных ретерн-кодов и тд.
я себе typedef с long unsigned int на uint сделала и проблем вроде пока не вижу.
Откройте для себя статические анализаторы.
Часть таких ошибок ловятся запретом применять < и >, когда достаточно == или !=.
в контексте выхода за границы массива как это поможет?
в любом случае нужно делать ++Iter и сравнивать с размером.
иль я туплю?
насколько я знаю, в современных высокоуровневых языках предлагается вообще не использовать индексы и итераторы. Обрабатывать коллекции предикатом, строить конвейеры данных и т.д.
было б неплохо, если бы "современные высокоуровневые языки" предложили что-то bash'евских массивов и for.
написал for Name in "${ArrName[@]}" и делаешь с Name шо угодно.
и проще, и довольно гибко.
for_each есть в Си++ со времён библиотеки "Степанов и Ли". Но и итераторы там вроде бы не считаются дурным тоном.
Вот именно! Например, в СОВРЕМЕННОМ языке D:foreach (index, flag; flags)
Это цикл по флагам, где каждый флаг появляется в flag + дополнительно имеем значение индекса в index! Вообще никаких гемороев по отслеживанию конца массива!
Но нет, все как сcыклuвые лемминги повторяют ахинею про "Ди не устоялся", зато на Ржу бегут толпами! *facepalm*
> в контексте выхода за границы массива как это поможет?
> в любом случае нужно делать ++Iter и сравнивать с размером.
> иль я туплю?Вот том и фокус: если при написании кода возникают такие вопросы, они помогают призадуматься и выявлять ошибки, когда глаз замылился и <= пишется на автомате, а код после автора никто не смотрит.
Прединкремент - это давнее требование к стилю в Си++, что бы в общем случае избежать лишней копии итератора. Оттуда же и ограничение на operator==().
Если с индексами, то и там в общем случае достаточно проверить граничное условие, т.е. !=. В том случае можно ведь заменить < на != ? В остальных зависит от конструкции цикла, иногда приходится потратить 5 минут на переоформление, но в сумме это экономнее по времени, чем позже ловить ошибки.
Довольно тупой рулез. У меня как раз такой хардкодинг с == != нещадно вырезается!!
Пример: функция возвращает -1 при ошибке или 0...индекс. Вызывающий код - если его писал зелёный салага, то будет так:if (fn() == -1) паника!
Но что если завтра я добавлю -2 в качестве индикатора ДРУГОЙ ошибки?! Тут его недальновидный код и сел в лужу (и ни один стат.анализатор это не отловит, т.к. по сути для него возвращаемое целое просто стравнивается с другим целым). Умный код будет такой:
if (fn() < 0) паника!
тут Вы в лужу сели - для этого есть errno.
> Довольно тупой рулез.Судя по баззворду, влез тот самый назойливый эксперт, не читающий тему. Советую почитать, хотя бы до слова "массив".
> У меня как раз такой хардкодинг с == != нещадно вырезается!!
Как видно, моё предложение делает даже больше заявленного. Отшить левых от проекта - задача необходимая для выживания.
> условно, в качестве процедуры тестирования...
> более того, с -fsanitize=undefined, gcc точно так же сует везде проверок. поэтому
> для обеспечения определенного поведения, в целом, достаточно обычного юнит-тестирования всвязке со сборкой парой компиляторов.В общем случае - не поможет. Возможно у тебя код проще.
А может ты просто пишешь лучше, чем среднестатистический писака ядра или каких-то серьезных либ.Вот пример: целая куча дыреней в OpenSSL/LibreSSL
www.opennet.ru/opennews/art.shtml?num=58622
чтение из области вне границ буфера, use-after-free, double-free, разыменование указателя NULL (x2) и тд.
А теперь смотрим на проект.
У них в тестах санитайзерами обмазано по самое не хочу: и address_ub_sanitizer, и memory_sanitizer, и threads_sanitizer, и ворниги компиляторов разнообразных, и фаззинг даже.
Но не помогло.> 2. раст ничего предложить кроме паники в UB не может. а паниковать не проблема и в С, да еще и код мой работать везде будет.
Запускаться будет (возможно).
А работать будет только при правильной версии компилятора.
Т.к UB позволяет вертеть поведением и делать его непредсказуемым.
Если СИ может паниковать, то чего ж он не паникует, а портит соседнюю память?> мне вот писал кто-то здесь не так давно про UB в С и то шо задетектить нереально, приводя в качестве примера переполнение signed номеров.
Да, к сожалению такая ошибка уже "одна из классических".
> но, честно сказать, так и не дошло, на кой их пользовать где-то за пределами четко известных ретерн-кодов и тд.
Возможно, потому что в книжках полувековой давности был такой пример. Он и кочует из кода в код)
> я себе typedef с long unsigned int на uint сделала и проблем вроде пока не вижу.
Адепты скорости осудят тебя.
Потому что u long int - это минимум 64 бита, а uint это минимум 16.
В проектах иногда пихают по 2 куска данных в одну переменную, чтобы побыстрее было.Проблема с UB в том, что даже одно убивает конформанс программы.
А их слишком много.
Получается, что практически любая программ, кроме простейшей, согласно стандарта СИ не будет strictly conforming.
А мы говорим про супер сложные кода, надежность которых должна быть маскимальной.
Но вместо этого берут кривой-косой инструмент((
из ссылки, как я поняла, основную опасность представляет какой-то косяк с типами.
>Если СИ может паниковать, то чего ж он не паникует, а портит соседнюю память?можно ж сделать, что б паниковал, нет?
я себе к проекту в добавок бойлерплейт пишу небольшой.
все что плохо лежать может - в доп. функцию и в ней сразу отлавливать ошибки. в связке с #define _POSIX_C_SOURCE, работать даже почти везде будет.
по поводу работы с памятью, ошибки *alloc'ов - это всегда не более, чем проверка errno, free() усмирить можно через проверку указателя на NULL и последующую установку на него же после очистки.
с разименованием нулевых тоже все относительно легко - в мане по каждой функции libc в разделах Return Values, Errors и Standards описано, кто кого и как возвращает.
я к своим подобное пишу в хедер-файлах пока.
если написано, что в случае неудачи функция сама не вызывает панику, дергаешь проверялку указателя(обязательно в if-условии, ибо иначе компилятор может порядок исполнения сменить) и либо самостоятельно шото с этим делаешь, либо дергаешь ту версию, что вместо, условно, возврата false, будет паниковать.
но это да, довольно неудобно бывает, поэтому такого по максимуму стараюсь не допускать. если что-то где-то как-то фейлится - оно ставит errno. а вызывающий просто errno проверяет.
в связке с небольшими косметическими макросами и бойлерплейтом, выглядет все довольно хорошо, читаемо(на мой взгляд и взгляд еще пары человек).
можно, например, передать вызов в макрос, он сам и код проверит, и панику вызовет.
+ в некоторых случаях, вызывающий может указать причину паники и функция, дергающая спец. "паникер", упадет не потому что "Runtime Error: ...", а потому что "File Not Found".
еще было б классно иметь что-то вроде питоновского with-блока.
может, это реально реализовать как-то, неуверена пока.
>Он и кочует из кода в кодкак, к слову, и Iter++ вместо ++Iter.
даже в коде systemd Iter++ делают.
сама недавно только узнала об этом.
>Адепты скорости осудят тебя.Потому что u long int - это минимум 64 бита, а uint это минимум 16.
я еще понять могу, когда за излишнюю дин. аллокацию ругают, а байты экономить не в коде для ембеддеда явно смысла нет. тем более, в условиях, где "шаг влево/вправо - расстрел".
при чем тут скорость вообще? это ж только на жручесть влияет, нет?
>Но вместо этого берут кривой-косой инструмент((он в спеке от IEEE и скомпилиться почти на любой микровалновке.
а раст.. он скорее как замена С++.
конечно, если всё делать аккуратно, то никаких ошибок и не будет. Но, видимо, не все люди одинаково ответственные и дисциплинированные.
> можно ж сделать, что б паниковал, нет?
> я себе к проекту в добавок бойлерплейт пишу небольшой.Но если оно не обязательно, то можно же не делать)?
Мы ж тут профи, это зеленые джуны будут так ошибаться (с)> по поводу работы с памятью, ошибки *alloc'ов - это всегда не более, чем проверка errno, free() усмирить можно через проверку указателя на NULL и последующую установку на него же после очистки.
То что ты описала это двольно сложно, если код многопоточный.
Например относительно недавнее отверстие в ХОргʼе (opennet.ru/opennews/art.shtml?num=58612) - там не занулили переменную и наткнулись на UB.
Значение указателя после вызова free() является неопределённым.
Причем даже не само значение памяти, которое по этому указателю, а даже само значение указателя.
- The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3).> с разименованием нулевых тоже все относительно легко - в мане по каждой функции libc в разделах Return Values, Errors и Standards описано, кто кого и как возвращает.
Если это зависить от компилятора (а еще круче, от его версии) то код получается нифига не переносимый.
> если написано, что в случае неудачи функция сама не вызывает панику, дергаешь проверялку указателя(обязательно в if-условии, ибо иначе компилятор может порядок исполнения сменить) и либо самостоятельно шото с этим делаешь, либо дергаешь ту версию, что вместо, условно, возврата false, будет паниковать.
Взять бы тебя... и отправить ядро писать)
А то там по какой-то причине с подобными проверками не заморачиваются.
Наверное слишком уверенны в себе :D> как, к слову, и Iter++ вместо ++Iter.
> даже в коде systemd Iter++ делают.
> сама недавно только узнала об этом.А если не секрет, сколько ты уже пишешь?
Потому что в си и плюсах есть куча таких "неявных особенностей", которые больше известны как "100500 способов отстрелить себе ногу")> он в спеке от IEEE и скомпилиться почти на любой микровалновке.
К сожалению, я читал стандарт СИ и он меня очень печалит.
Особенно раздел conformance. Т.к согластно нему, получить strict conformance практически невозможно.
Если добавить к этому то, что реализация стандарта не обязательна и каждый компиятор может просто не реализовывать какие-то куски стандарта (en.cppreference.com/w/c/compiler_support)..
То вопрос "а почему это вообще называется стандартом" остается открытым.Например в С23 добавали UB на код, который раньше был ID.
Как поведет в этом случае написанный код низнает никто.> а раст.. он скорее как замена С++.
Пока его пытаются добавать в ядро, а плюсы туда не пустили (хотя мне кажется что зря).
В андроиде гугл заменяет кода на си и плюсах на раст - значит оно подходит и для первого, и для второго.
>Но если оно не обязательно, то можно же не делать)?а как? мне надо posix'y следовать, ни раст, ни с++ не катят.
>The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3).это откуда инфа?
в 7.20.3 из спеки с99 только:
>The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined.в последнем там вообще "limits of int types". в posix по этой теме ничего.
никакой критики в сторону установки на NULL не нашла.
в любом случае, никто не мешает сделать все то же самое, но с доп. структурой и набором макросов.
>даже само значение указателятак если его поставить на NULL, он ж и будет NULL. то что кто-то обнулить забыл - это дело уже десятое.
хотя, не знаю, как можно забыть обнулить, если очистка делается только через функцию, которая и ставит, и проверяет.
может быть, конечно, такое, что, к примеру, кто-то новый закоммитил и использовал free(), но тогда вопрос, почему free() еще не заглушен чем-нибудь(условно, в главном хедере либы включать в первую очередь то, что отвечает за обработку памяти, а потом сразу же файл с заглушками, я так и сделала)?
в новости-то именно обнулить забыли, а не "обнулили и получили из-за этого баг".
>Если это зависить от компилятораи поведение компилятора, и повидение компонентов libc, описано в POSIX.
>А то там по какой-то причине с подобными проверками не заморачиваются.так и не дошло, почему.
скорее всего замедления боятся или что-то в этом роде? но как будто бы просто пару раз значение int-переменной проверить не так уж много времени отъедает.
тем более, часто можно в кол.-ве проверок именно за счет errno выиграть.
тоже хз, почему его не используют, слышала только мнение, что он "исключительно для компонентов libc", но как бы .. заведи себе другую переменную и проблем не знай.
почему в systemd всем плевать - я не знаю.
еще не знаю что за афигенная привычка у некоторых товарищей давать имена в стиле "imyamoyeyperemennoy". хотела недавно код из dash подсмотреть, так и не поняла, о чем там.>А если не секрет, сколько ты уже пишешь?
где-то месяца полтора.
>т.к согластно нему, получить strict conformance практически невозможно.
для этого есть posix. куча вещей описывается, куча форсируется.
в результате, можно ожидать вполне предсказуемой реализации.
>Например в С23 добавали UB на код, который раньше был ID.это тоже posix решает.
да и пишут обычно под конкретную версию стандарта, а не с99+, например.>Пока его пытаются добавать в ядро, а плюсы туда не пустили (хотя мне кажется что зря).
В андроиде гугл заменяет кода на си и плюсах на раст - значит оно подходит и для первого, и для второго.
что-то мне подсказывает, что им "молодой крови" не хватает.
и, пропустив шанс ее завлечь с с++, сейчас пытаются не опростоволоситься.
ну и раст пока почище плюсов будет.
>это откуда инфа?не то в цитату выделила, подумала, что речь о "установка на NULL и проверка - UB".
> это откуда инфа?
> в 7.20.3 из спеки с99 толькоЭто улучшения в С23.
Жить стало лучше, жить стало веселей (с)
Причем мотивация комитета просто гениальная. В стиле "раньше было плохо, а мы сделаем еще хуже".Т.к POSIX и реализации для realloc(ptr, 0) ведут себя по-разному,
Classifying a call to realloc with a size of 0 as undefined behavior would allow POSIX to define the otherwise undefined behavior however they please.
то давайте сделаем не ID (т.е конкретный список возможных вариантов), а UB - т.к ХЗ что.
Making this behavior undefined continues to allow existing implementations to do as they please, but provides a clear warning to developers to guard against zero-byte reallocations.По поводу NULL я наверное не очень понятно выразился.
В стандарте СИ есть такое
The behavior is undefined in the following circumstances:
...
The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.20.3).Т.е код
int *А = malloc(16);
printf("%p\n", А);
free(А);
то любое взаиможействие с А - это будет UB.
Например повторный
printf("%p\n", А);Раз программа содержит UB, то о strictly confirm можно забыть.
Корретность кода становится под вопросом.
А такой код написать ну очень просто.
жесть.
в коммитете забыли, что posiх их дальше 99й версии не признает?
>любое взаимойдействие с A будет UBпоэтому при получении указателей от вызывающего - проверка, проблемы особо не вижу.
>>А то там по какой-то причине с подобными проверками не заморачиваются.
>так и не дошло, почему.Мне кажется, что по причине "мы уверенны в своем коде и своем опыте".
Ну и в том, что нужна скорость любой ценой.
В старых программах очень любили использовать (не|слабо)документированные хаки ради ускорения.Например когда (2021) ядро стало собираться с Werror по умолчанию, то тонны хаков отвалились.
phoronix.com/news/Linux-5.15-Werror-Pain
Настолько, что даже попытались п̶р̶о̶в̶е̶р̶н̶у̶т̶ь̶ ̶ф̶а̶р̶ш̶ ̶о̶б̶р̶а̶т̶н̶о̶ сделать реверт
patchwork.kernel.org/project/linux-kbuild/patch/20210907183843.33028-1-ndesaulniers@google.com/#24432767> скорее всего замедления боятся или что-то в этом роде? но как будто бы просто пару раз значение int-переменной проверить не так уж много времени отъедает.
> тем более, часто можно в кол.-ве проверок именно за счет errno выиграть.Иногда мне попадались мнения, что присваивать NULL после free это вредно, тк тратятся лишние такты процессора.
Так что ты права, люди хотят экономить максимально, даже там где это не нужно.
Просто по привычке или из-за карго культа.> еще не знаю что за афигенная привычка у некоторых товарищей давать имена в стиле "imyamoyeyperemennoy". хотела недавно код из dash подсмотреть, так и не поняла, о чем там.
Без капитализации выглядит не очень.
Но зависит от принятых стандартов в проекте.
В моих идет camelCase, где переменные вида iAndMyCodeIsAvesome.
Но я абсоkютно спокойно отношусь и к some_stupid_variable.
Это все вкусовщина и за много лет просто привыкаешь. Ну типа как "есть брюнетки и блондинки.. both, both is good (c)"> для этого есть posix. куча вещей описывается, куча форсируется.
> в результате, можно ожидать вполне предсказуемой реализации.К сожалению нет.
В прошлом сообщении я как раз писал, что реализации и стандарты это очень разные вещи.> что-то мне подсказывает, что им "молодой крови" не хватает.
О, интересное мнение, которое очень не популярно на этом форуме))
Тут любят гнобить "смузихлебов" и "снежинок", ну и политься на дидов.> ну и раст пока почище плюсов будет.
Плюсы вообще делались как надстройка над СИ.
И Страуструп в своем недавнем интервью вообще заявил "У меня не было знаний, чтобы создать с нуля язык программирования".>>А если не секрет, сколько ты уже пишешь?
> где-то месяца полтора.Тогда удачи.
У тебя будет еще много интересных и неожиданных открытий.
>К сожалению нет.В прошлом сообщении я как раз писал, что реализации и стандарты это очень разные вещи.
так нет ведь.
в POSIX с UB/ID куда осторожнее, любая неопределенность(как правило, довольно некритичная) решается обычной проверкой этого состояния в бойлерплейте.
ну и там уж делать что-то на свое усмотрение.
если же реализация стандарту не следует, или реализует другой - то это уже и не моя проблема, ибо работа была заявлена в окружении, реализующем конкретный стандарт конкретной версии.>Плюсы вообще делались как надстройка над СИ.
так а раст?
только там даже не над С, а во многом над кишками llvm.
Даже POSIX имеет много версий.
И меня терзают смутные сомнения, что код для ISO/IEC 9945-1:1990 будет работать с 2017 (последний стандарт).
Даже на сайте ISO старые считаются отозванными iso.org/standard/17840.html.Новый POSIX.1-2024 предлагает вообще тонну новых функций и удаление старых, причем довольно много. Как поведет себя некрософт вопрос, подозреваю что плохо
(sortix.org/blog/posix-2024/)
А профили 1003.13 вообще не поддерживают все ОС.> так а раст?
> только там даже не над С, а во многом над кишками llvm.Неа) Тут ты не права.
У Раста есть фронт и бек, как у многих языков которые делались под llvm
Изначально компилятор писался на окалме, а потом переписали на сам раст (rustc).
Но это фронт.А бек у него был с использованием llvm (который написан на С++).
Но есть и альтернатива в виде cranelift - бекенд написанный полностью на расте.
Т.е есть у нас есть рабочий вариант "rust front + rust back".
>поведет себя некрософт вопрос,у него, как правило, #define _POSIX_C_SOURCЕ на таргет-версию.
и времени на переписывание у разрабов минимум лет 7.
под 2018й и то без опасок до сих пор писать нельзя, потому, все в основном пишут под 2008й.
сейчас, конечно, почти везде 2018й стандарт реализован, но некоторые окружения с 2008ым есть еще.в случае с утилитами, да, действительно, можно огрести, способа получить версию реализованного стандарта, например, в шелле - нельзя.
справедливости ради, все удаления предварительно помечаются как deprecated(лет эдак на.. 20? скольо там $[] для математики держат?), и часто там же предоставляется новый способ, особо проблем не создающий. поэтому даже переписывать мало что нужно при мажорных изменениях в стандарте и использовании deprected-функционала программой.при том, благодаря "рекурсивной" поддержке, стандарт не превращается особо в помойку, а все, что использовать нинада, четко выделено.
>Неа)
хм.. глянула, действительно.
а мне в чате в матрице один человек пару месяцев назад рассказывал, что раст полностью на интристиках llvm'а.
тем не менее, кто код-то генерирует и какой? cranelift что делает? С-код компилит?
или там свой байткод уже?
>кто код-то генерирует и какой?https://blog.rust-lang.org/2016/04/19/MIR.html
Вроде как компилятор Rust переводит программу в свою собственную промежуточную форму mir, а её уже в llvm или wasm
> по поводу работы с памятью, ошибки *alloc'ов - это всегда не более, чем проверка errno,errno сам по себе привносит возможностей наступить на грабли, поскольку это статическая переменная. Грабли от конкурентности вроде победили сделав errno thread-local, но реентерабельности как не было, так и нет и не будет никогда. Поэтому надо очень внимательно следить за тем, чтобы между выставлением errno в значение ошибки и проверкой этого значения не влез бы ещё какой-нибудь код, который тоже захочет errno поменять. С учётом того, что между выставлением значения errno и кодом проверки как правило несколько стековых фреймов, то не наступить на эти грабли становится довольно сложно. Достаточно сложно, чтобы на них регулярно кто-нибудь наступал.
> free() усмирить можно через проверку указателя на NULL и последующую установку на него же после очистки.
Кек. Это если ты знаешь все места, где этот адрес хранится. Тогда да, тогда можно все их занулить после free. Или лучше, на всякий случай, сначала их все занулить, а потом сделать free на значение взятое из локальной переменной. Но это если ты можешь перечислить все места, где адрес хранится. Программисты очень часто упускают какую-нибудь локацию. Вот тут занулили, free вызвали, а там указатель остался ждать, когда какой-нибудь код наступит на use-after-free.
Но при этом бывают ещё более интересные ситуации, когда пытаясь наэкономить аллокаций, пытаешься выделять на стеке, но не всегда получается, и в какой-то момент понимаешь, что не знаешь куда указатель указывает, на стек или в кучу, потому то в зависимости от предыдущих ветвлений может быть либо то, либо это. И это ещё хорошая ситуация, когда понимаешь, что не знаешь, можно разрулить ситуацию. Хуже бывает, когда думаешь что знаешь, но ошибаешься. Именно подобные ситуации легко могут привести к возврату из функции указателя на локальный массив. Или к free на стековый адрес, или к мемлику, или к use-after-free, или к double-free. Именно поэтому сишный код пишется довольно консервативно, без особого старания избегать аллокаций любой ценой, потому что цена легко может стать неподъёмной.
> с разименованием нулевых тоже все относительно легко - в мане по каждой функции libc в разделах Return Values, Errors и Standards описано, кто кого и как возвращает.
Это отстой же. Никакого контроля за программистом, что он прочитал ман и не забыл обработать ошибку. То ли дело Maybe/Option/Result: возвращаемым значением не воспользоваться, не обработав ошибку. Зачем писать в комментах и манах то, что можно описать заголовком функции, и пускай дальше компилятор энфорсит использование функции согласно заголовку.
> байты экономить не в коде для ембеддеда явно смысла нет.
Ну это смотря где. Загляни в sparse[1], ты увидишь как там Торвальдс в парсере C _биты_ экономил. Один лишний байт в структуре -- это не проблема, до тех пор, пока ты не создашь миллиона таких структур, превратив этот лишний байт в лишний мегабайт. Или в несколько мегабайт, если размер структуры выравнивается до кратного 8, и этот дополнительный байт как раз перевалил через эту границу. Но Торвальдс, я подозреваю, больше заботился о том, чтобы структуру можно было бы по значению передавать везде, и чтобы она при этом минимум регистров занимала бы, оставляя как можно больше регистров под другие аргументы. Ситуация может ещё усугубиться (не в случае sparse, а в общем случае), если многопоток, причём особенно если юзерспейс многопоток, позволяющий миллионы тредов гонять с минимумом оверхеда: чем больше структуры, тем больше стека выделять надо под каждый тред, стек надо выделять с запасом, и... нутыпонел. Если ожидаемый размер стека вырос на N байт, но мы не можем посчитать точно, значит надо накинуть 2*N или может 10*N, так чтобы наверняка.
В целом, конечно, байтом больше, байтом меньше, какая разница. И часто это работает. А иногда получаются электроны, которые выжирают несколько сотен мегабайт даже если программа на электроне ничего не делает.
>errno сам по себе привносит возможностей наступить на граблиоб этом в разделе NOTES в мане написано описан правильный путь обхода.
я так делаю:
Call1();
catch {
catchExact(EINVAL){
printf("%s\n", "EINVAL!");
exit(3);
}
exit(1);
}catch - сохраняет errno в локальную переменную, ставит на 0, потом проверяет локальную.
catchExact - так
же смотрит в локальную.
поэтому достаточно просто catch совать сразу после вызова, а там уж делать, что угодно.
ставится errno через throw(Code, FailReturn), но он и завершение сразу дергает, поэтому ситуаций, когда отправленный код кто-то перебьет, не возникает.>Вот тут занулили, free вызвали, а там указатель остался ждать, когда какой-нибудь код наступит на use-after-free.
ну, во-первых, вызвали не free, а бойлерплейт, который сразу все занулит.
во-вторых, перед использованием "левого" указателя(того, который передал вызывающий, например), дергаем уже другой бойлерплейт, который указатель проверит и запаникует в случае чего.
<...>PointVerify(point1, point2) {
// Process point1, point2
}но тут важно: бойлерплейт должен дергать if и взаимодействовать с указателем только если все окей, вещи вроде
if (!<...>) { exit(1); }
не пойдут, т.к. компилятор может спокойно порядок исполнение поменять.>из функции указателя на локальный массив.
это обычно компилятор контроллирует, без примера я тут мало что скажу.
>Это отстой же.
это цена портабельности же.
никто, опять же, не мешает вокруг стандартных функций добавить бойлерплейт для авто-отлова. я так и делаю сейчас. в голове в итоге держать приходится не очень мнрго, ибо знаю, что в случае чего будет паника и я это увижу в любом случае.
> ли дело Maybe/Option/Resultну будет Maybe/Option/Result в общепринятом стандарте - тогда и будет "то ли дело".
я момент с posix'ом специально выделила. не было б такой задачи - я б и дальше на cs писала.>Загляни в
мне в каждый файл в репе заглянуть?
по ссылке - summary репозитория.
> об этом в разделе NOTES в мане написано описан правильный путь обхода.Мало ли что там написано, язык доверяет программисту, что тот не забудет это сделать. Но весь опыт программирования показывает, что программисту нельзя доверять. Есть подход "доверяй, но проверяй", но он работает только тогда, когда проверка работы программиста как минимум на порядок проще чем работа программиста. errno не отличается таким свойством: чтобы убедиться что работа с ним корректна, придётся обойти всё дерево вызовов, найти все места где errno может меняться теоретически, убедиться что во всех местах где errno может практически меняться совершены все необходимые ритуалы, чтобы не затереть ещё необработанное значение errno. Проще самому написать программу с нуля, чем проверять все эти вещи.
> ну, во-первых, вызвали не free, а бойлерплейт, который сразу все занулит.
Ты о чём сейчас? Что за бойлерплейт? Представь, у тебя наворочаны какие-то структуры данных, и где-то в них есть три указателя хранящих адрес, который ты хочешь занулить. При этом, возможно, этот адрес есть ещё где-то в локальных переменных выше по стеку. Как ты будешь это делать? А теперь представь ещё, что ты ошибаешься, и в твоих структурах этот адрес сохранён в пяти местах, а не трёх. Хочешь ещё усложнений? У тебя многопоточная программа, и к тому адресу обращаются другие потоки, то есть у них на стеках тоже может хранится этот адрес. А, ещё там может хранится не сам адрес на объект, а адрес на какую-то часть объекта, например, не адрес заголовка списка, а адрес какого-то элемента внутри списка.
Если это всё кажется слишком абстрактным, я тебе могу конкретный сценарий нарисовать. Он не демонстрирует всего вышеперечисленного (всё сразу вряд ли возможно продемонстрировать одним примером), но создаёт некий контекст. Например, допустим у нас есть функция log:
void log(enum LogLevel level, char* format, ...);
И допустим, что этот log собирает свои аргументы в структурку и заталкивает её в очередь, чтобы когда логирующий поток доберётся до этого сообщения, он бы его отформатировал и отправил бы во все места куда логи ведутся. И допустим, я делаю так:
do_smth_with_file(char* fname) {
FILE *f = fopen(fname, "r");
log(LogLevelNotice, "successfuly opened file {}, got {}", fname, f);потом я что-то делаю с файлом, а потом:
log(LogLevelNotice, "I'm going to close the file {}", f);
fclose(f);Упс. Я получил датарейс ведущий к use-after-free. Если log не успеет передать в логирующий поток всё, чтобы тот успел бы извлечь из f все нужные ему поля, чтобы отформатировать сообщение, прежде чем будет вызвана fclose, то тут use-after-free. Пример кажется высосанным из пальца? Давай я накину возможную мотивацию для такой архитектуры логирования. Логирующий поток может хранить один буфер под все сообщения и форматировать их туда, что даст нам вместо O(N) аллокаций, где N это количество сообщений в логе, O(1) аллокаций, когда логирующий поток выделяет и перевыделяет буфер небольшое количество раз (<10) за время жизни программы, нащупывая самую большую используемую длину сообщения. При этом, хочется логирование в отдельный поток засунуть, чтобы не повреждать себе latency дополнительно: логирующий поток может блокироваться на вводе/выводе, и пускай он блокируется, но эти блокирования не будут мешать основной программе.
Там есть ещё один датарейс, если ты не заметил: первый вызов log передаёт указатель из локальной переменной-аргумента. Эта локальная переменная прекратит существовать когда функция завершится. Строка, на которую она указывает переживёт функцию (если та не делает free(fname)), но сколько она проживёт ещё? А никто не знает. Может быть после вызова нашей дебильной функции в вызывающем коде сразу освобождение памяти. Или может строка на стеке лежит, и после очередного return она будет лежать вне стека.
Тут не важно, какой бойлерплейт ты наворачиваешь поверх free, проблема в том, что надо перебрать все места, где адрес хранится и запросто может оказаться, что не все места достижимы для твоего кода которому вдруг приспичило удалить объект. Стек другого потока недостижим, стековые фреймы кроме текущего недостижимы, все сложные разветвлённые структуры состоящие из миллиардов объектов недостижимы, если указатель на них не передан аргументом и не хранится в глобальной переменной. То есть даже зайти подходом консервативного сборщика мусора не удастся.
В целом, если тебе кажется, что проблема правильно расставить malloc/free -- это тривиальная проблема, то это говорит только о том, что ты не понимаешь проблемы. Ты можешь использовать это правило в качестве детектора людей далёких от программирования, рассуждающих об управлении памятью.
> это обычно компилятор контроллирует, без примера я тут мало что скажу.
C не контролирует или контролирует в тривиальных случаях. Добавь чутка осложнений...
char *foo(char *in) {
char *local_str = "1234";
return longest_string_of_two(in, local_str);
}... и компилятор не справится.
> это цена портабельности же.
Плевал я на портабельность, которая хочет от меня, чтобы я такую цену платил.
> никто, опять же, не мешает вокруг стандартных функций добавить бойлерплейт для авто-отлова.
Если этим заняться серьёзно, а не на полшишечки, то ты получишь rust.
> ну будет Maybe/Option/Result в общепринятом стандарте - тогда и будет "то ли дело".
> я момент с posix'ом специально выделила. не было б такой задачи - я б и дальше на cs писала.Ой, да ладно, что ты к этому позикс прицепился.
fn posix_open(fname: Path) -> Result<FileDescr, IOError> {
let ret = unsafe { syscall::open(
fname.as_osstr(),
syscall::OpenFlags::default(),
syscall::OpenMode::default(),
)};
if ret < 0 {
IOError::from_syscall_ret(ret)
} else {
FileDescr::from_int(ret)
}
}И всё, и нет никакого позикс. То есть он как бы и есть, со всеми его недостатками, но мы его спрятали, и теперь его недостатки нам по-барабану. Нет, например, errno, потому что ядро возвращает код ошибки значением. Нет C'шных enum'ов, которые позволяют любое значение int'а просунуть, помимо перечисленных в enum.
errno это legacy из 80-х. В C неудобно пользоваться другими способами, тот же tagged enum создавать, который сможет хранить либо возвращаемое значение функции, либо ошибку, можно, но при отсутствии параметризации, придётся на каждую пару типов возвращаемого значения и ошибки создавать новый enum. Из-за этих неудобств программисты начали халявить со статической переменной. И даже если это posix, то это не пример для подражания, более того зашквар этим пользоваться для современного программиста. С позиксовыми функциями часто иначе не удастся, ок, но зависимость от errno должна прекращаться на границе позиксового кода и твоего.
> мне в каждый файл в репе заглянуть?
Зачем же в каждый. Начни с main.c, и посмотри как программа обходится с передачей подстрок в функции и возврату их из функций. Но я б рекомендовал не останавливаться на этом, а читать эти сорцы на сон грядущий вместо того комиксов, которые ты читаешь. Это очень неплохой пример, как надо писать на C, плюс это пример recursive descent парсера.
> по ссылке - summary репозитория.
Ну, главная страница репа. Она напрашивается как выбор точки входа. Можно было ещё homepage взять такой точкой входа, но... уже как получилось, так получилось.
>Ты о чём сейчас?о том, что негоже напрямую все кишки вываливать. проще, безопаснее все в define'е/функции спрятать.
>И допустим, я делаю так:
пример, как абстрактным был, так таковым и остался. ибо Вы проблемную функцию спрятали.
я не поняла ничего, честно сказать, все так же не могу ничего ответить, ибо не вижу, что у Вас там в log().
мне так же не ясно, зачем Вы логгеру передаете FILE* ?
он в него писать будет?
почему тогда открывает вызывающий, а не глав. поток логгирования?
и почему он как vararg передается?
шо вообще там происходит?>longest_string_of_two
#include <stdio.h>
char *getLongestStr(char *str1, char *str2){
if (strlen(str1)>strlen(str2)){
return str1;
}
else {
return str2;
}
}char *foo(char *in) {
char *local_str = "1234";
return getLongestStr(in, local_str);
}int main(void){
printf("%s\n", foo("12"));
}вот с реализацией.
UB нет. или я поняла Вас неверно?
>Плевал я на портабельностьдержете в курсе? ладно. надо было с этого начать.
>И всё, и нет никакого позиксдействительно. ведь Вы реализовали черт-те что на нестандартизированном языке.
если бы "POSIX-совместимость" предполагала "реализовать функции из POSIХ libc на любом языке", я бы это все не писала :)>errno это legacy из 80-х.
я Вам выше про него написала.
Вы ничего "по факту" не сказали, только про легаси.
> даже если это posix, то это не пример для подражания, более того зашквар этим пользоваться для современного программистану, уж извините, IEEE в этом мире больше решает, чем мнение анонима на опеннете.
касаемо Линусовского кода - мое заявление было скорее про случаи, когда "по 2 значения в переменную пихают", на NULL ставить указатели бояться, экономя "такты процессора".
> я не поняла ничего, честно сказать, все так же не могу ничего ответить, ибо не вижу, что у Вас там в log().Пфф... Например она может выглядеть так:
static InterThreadChannel log_channel;
void log(enum LogLevel level, char *fmt, ...) {
va_list args;
va_start(args, fmt);
ChannelMsg msg = {
.level = level,
.fmt = fmt,
.args = collect_ellipsis_args(args),
};
log_channel.send(msg);
}Так понятнее стало? Или надо пояснить, что на том конце channel'а?
Что-то типа:
char *buf = NULL;
size_t bsize;while(true) {
ChannelMsg msg = log_channel.get();
logger_format(&buf, &bsize, msg); // представь себе, что идейно это что-то типа asprintf, только вместо varargs аргументы получает структурой и свой синтаксис форматной строки реализует
write_msg_to_log_file(buf);
write_msg_to_loggin_server(buf);
write_msg_to_whatever(buf);
}Теперь понятно?
> вот с реализацией.
> UB нет. или я поняла Вас неверно?Глаза разуй. Вот представь себе, я пишу код, который вызывает foo:
char *s = foo();
// тут я делаю много полезных вещей с s
// ещё немного полезных вещей
// ...
// дело подходит к концу функции, s нам больше не нужен, и я такой:
free(s);
return;
}Теперь ты видишь UB? Или может я должен поступить так:
// ...
// дело подходит к концу функции, s нам больше не нужен, и я такой:
return;
}Как думаешь? Что лучше: memleak или повреждение кучи?
> действительно. ведь Вы реализовали черт-те что на нестандартизированном языке.
Стандарт позикс не накладывает никаких ограничений на язык, мною используемый, и на то, что я на нём буду писать. Если бы он накладывал, то это был бы не позикс, а Apple. Таким образом, моя программа полностью соответствует стандарту POSIX.
> Вы ничего "по факту" не сказали, только про легаси.
То, что я сказал, для тебя "ничего"? Если ты требуешь от программиста пропрыгивать через кольца для того, чтобы получить надёжный код, но оставляешь ему лазейку, как получить видимо работающий код без всех этих сложностей, то глупо рассчитывать на то, что в результате выйдет надёжный код. Если ты этого не понимаешь, то это от отсутствия опыта работы с другими программистами.
>>longest_string_of_two
> ...
> вот с реализацией.
> UB нет. или я поняла Вас неверно?Со "строками" - это был наброс от тролля:
1. В Си нет string.
2. Когда два массива char имеют равную длину, что может вернуть предполагаемая функция? longest_string_of_two - сферический конь в вакууме и на деле не имеет смысла возвращать указатель.
3. Когда программе требуется много чего делать с текстом, то строки хранятся в специально для того придуманном виде. Например, в NT это UNICODE_STRING, а у остальных своё.
> Ну это смотря где. Загляни в sparse[1], ты увидишь как там Торвальдс в парсере C _биты_ экономил. Один лишний байт в структуре -- это не проблема, до тех пор, пока ты не создашь миллиона таких структур, превратив этот лишний байт в лишний мегабайт.Интересно, насколько это увеличивает вероятность ошибки.
И как оно потом выглядит после оптимизаций.> Или в несколько мегабайт, если размер структуры выравнивается до кратного 8, и этот дополнительный байт как раз перевалил через эту границу. Но Торвальдс, я подозреваю, больше заботился о том, чтобы структуру можно было бы по значению передавать везде, и чтобы она при этом минимум регистров занимала бы, оставляя как можно больше регистров под другие аргументы.
Предположу, что это было актуально для техники 91 года, когда писалось ядро.
А это были темные времена, даже до первого пентиума.
Насколько оно актуально сейчас?
(когда кеш в современной ряжанке, больше чем оператива моего первого компа).
Может такие сверх оптимизации нужны только для 8битных микроконтроллеров?
> Интересно, насколько это увеличивает вероятность ошибки.Это уменьшает допустимые размеры для токенов, там поля типа size вовсе не u64, и даже не u32, то есть идентификатор на 4 гигабайта sparse не сможет прожевать.
> Предположу, что это было актуально для техники 91 года, когда писалось ядро.
> А это были темные времена, даже до первого пентиума.
> Насколько оно актуально сейчас?Актуально. Но тут тебе придётся верить мне на слово, потому что у меня нет ссылки, я не сохранял её в закладках, потому что не думал, что кому-нибудь она будет полезна. Я пару лет назад читал разбор полётов, в котором чувак пытаясь разобраться в том, куда сжираются гигабайты оперативки, доковырялся до используемых им структур, и переупорядочив поля там, эти самые гигабайты сэкономил. Там была именно ситуация зиллионов инстансов этих структур. Чувак очень радовался своим обретённым познаниям о том, как упаковываются C'шные структуры, и о том, как эти структуры лучше всего писать. Это знания, которые при программировании под DOS считались азами программирования на C, которые усваивались вместе с синтаксисом C, но видимо свежим поколениям программистов это уже дают элективным курсом, и некоторые пропускают.
Плюс ты упускаешь из виду то, что каким бы твой кеш не был большим, в него не лезет всё. И если ты впихнёшь в него на десять процентов больше инстансов структур, то твой код будет работать примерно на 10% быстрее. Тут уже работает даже не абсолютное снижение размера, а относительное.
>> Насколько оно актуально сейчас?
> Актуально. Но тут тебе придётся верить мне на слово, потому что у меня нет ссылки, я не сохранял её в закладках, потому что не думал, что кому-нибудь она будет полезна.Да, без проблем. У меня познания в настолько низкоуровневом программинге не слишком большие.
Поэтому и спрашиваю)> Там была именно ситуация зиллионов инстансов этих структур.
Мои познания оказались еще хуже чем я думал)
Насколько я понимаю, это утилита для стат. анализа кода.
Т.е она проверяет корректность кода и какие-то синтаксические ошибки. Но стат анализаторов для СИ дофига, чем это настолько крут?
Что будет если она замедлится? Ядро будет тормозить или просто дольше собираться?> Это знания, которые при программировании под DOS считались азами программирования на C, которые усваивались вместе с синтаксисом C, но видимо свежим поколениям программистов это уже дают элективным курсом, и некоторые пропускают.
Так на СИ молодым ИМХО особо нет смысла даже учиться.
Только если идти в эмбедедщину или пилить ядро и прочие легаси.
> твой код будет работать примерно на 10% быстрее. Тут уже работает даже не абсолютное снижение размера, а относительное.Вот это меня и напрягает.
В таком коде ошибиться очень легко.
Стоит ли ускорение аж на 10% повышения шанса поймать какую-то бяку?
Вон интел наускорял +5%, а потом отгреб со спектрами и мелтдаунами.Ps а что ты думаешь про последнее интервью Торвальдса и его заявление
"You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."
> по поводу работы с памятью, ошибки *alloc'ов - это всегда не более, чем проверка errnoГосподи, 21 век на дворе! Проверка errno :)) (скупая слеза пробежала по лицу сишаописта)
Почему ты не пишешь на C#? Отличный язык, громаднейшая библиотека, корпорация за плечами, признание рынка... это ж мечта! Но нет, луддиты нихьт! Будут сипипискать, растаманить, даже пестонить, но на неправославном C# писать не будут! :))
зпочему ты так уверен в своих экстрасенсорных способностях?
проект изначально на cs и был)
но, как, надеюсь, сишарпист, понимаешь, clr нигде, кроме винды, макоси и линукса не пашет.
стояла задача следовать POSIX'у.
$cat test.cc
int main(int argc, char **argv) {
int k = 0x7fffffff;
k += argc;
return 0;
}
$clang++ -fsanitize=undefined test.cc
./a.out
test.cc:3:5: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'Проект Clang также делает статический анализатор, наверное в нём этот самый пресловутый искусственный интеллект уже есть.
А вообще, с Clang надо осторожней, столкнулся с ошибками в компиляторе и отладчике. Ещё бывает что Clang генерирует совершенно левый код, бессмысленный, который только замедляет работу. По-правильному, нельзя доверять ни одному компилятору, надо дизассемблировать все свои программы и проверять.
статический - это когда Вы файл кидаете и он Вам тыкает сразу.
а тут - скомпиль, запусти и молись еще, что на свою ошибку наткнешься.
иногда довольно сложно это все отлавливать, даже с ubsan'ами
Может тогда лучше использовать не С, а С++ ? С++ настолько ненадёжный , что валится от любой ошибки. Программа на С++ строится на невидимом каркасе обработки исключений (даже если в программе нет кода выброса и ловли исключений). этот каркас очень хрупкий, и ломается почти от любой ошибки, хоть с памятью, хоть с потоками. Ошибку будет невозможно не заметить, потому что выдаст странное исключение или abort. Если что, можно и valgrind'ом проверить.
так тогда б я раст предпочла.
стоит задача posiх'у следовать
uucp, m4... некрофилия какая-то
Зато это родные трупы! :)) На них завязаны какие-нть перделки (на m4 точно). Хотя мне слабо верится, что с 70-го года рынок юникса настолько остался тухлым. Вернее, сама ИТ отрасль! Появилась мультимедия - звук, видосы, всякая биг дата, блокчейны, сошиал-сервисы... а линynсисты всё текст по пайпам гоняют! Это же глупо и устарело лет 30 назад. Набор утилит уже давно должен быть другой, с переосмыслением под современность.
> не планирует обеспечивать совместимость с утилитами GNU, функциональность которых воспринимается авторами как необоснованно раздутаямало ли, что они и как воспринимают
если не обеспечат полную совместимость, то пользователи сами не поменяют один инструмент на другой
и если нет административного ресурса в лице red hat, то не светит им нифига
> если не обеспечат полную совместимость, то пользователи сами не поменяют один инструмент на другойЕсли их не будет устраивать новый.
Например - они не работают с некрософтом.> и если нет административного ресурса в лице red hat, то не светит им нифига
Именно для этого нужна красношапка - чтобы выкидывать устаревший мусор.
Т.к если неколюбов слушать - то до сих пор на телеге с лошадь передвигались.
так-то POSIX'овая реализация старше гнутой.
полную совместимость обеспечивают со стандарнтом, а не с докой левой реализации.
А почему тогда у нас есть POSIX-certified и Formerly POSIX-certified (хотя автотесты эти ʼбывшиеʼ проходят) ?
Но еще есть Mostly POSIX-compliant - наверное 'POSIX на полшишечки'.
Причем в последних вполне распространенные системы типа Android, Darwin и тадам Linux (кроме нескольких дистрибутивов).Так что обеспечение полной совместимости, на мой взгляд бесполезная фигня.
Но я конечно не знаю какую задачу ты решаешь, может там это обязательно, что прям кровь-из-носу.
потому что у одних есть сомвместимость и бумажка, а у других - бумажки нет.
>наверное 'POSIX на полшишечки'."POSIX на 90+% шышечки" в основном.
зависет от реализации.
вообще, я к тому вела, что не ясно, чем и как реализовывать GNU-расширения: ни стандарта, ни процедуры принятия, ничерта. только доки от авторов, не гарантирующие и не принятые формально никем.
> вообще, я к тому вела, что не ясно, чем и как реализовывать
> GNU-расширения: ни стандарта, ни процедуры принятия, ничерта. только доки от авторов, не гарантирующие и не принятые формально никем.Здорово, правда! (с)
От так и живем.
Но если вернуться к сабжу - то на фоне всего остального "отсутствие совмести с ГНУ" это будут проблемы ГНУшников)
А кому надо - тот будет использоватью
> полную совместимость обеспечивают со стандарнтом, а не с докой левой реализации.очевидно, что Вы никогда не задумывались о том, откуда появляются стандарты
почитайте на досуге, Вас ждёт много интересных открытий
как, очевидно, и 100500 систем, реализующих POSIX.
поэтому совершенно наплевать.
потратила только что 30 мин на написание 2х комментариев.
ве, короче,ухожу с опеннета, ловите на слове!
> потратила только что 30 мин на написание 2х комментариев.
> ве, короче,ухожу с опеннета, ловите на слове!Ну с тобой хотя бы поговорить как с человеком можно.
Напоминает темы на ЛОРʼе где могут 10 страниц обсуждать особенность UB в С++.Но работать тоже приходится))
Женщины так всегда, сначала ворвутся в душу ... то есть, я хотел сказать, в чат, а потом убегут, оставив в недоумении: что это было?
> ве, короче,ухожу с опеннета, ловите на слове!Слова хватило аж на неделю. =)
А как быстро это работает на Raspberry Pi?