The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в утилите GNU split, приводящая к переполнению буфера, opennews (??), 24-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


19. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –3 +/–
Сообщение от нах. (?), 24-Янв-24, 11:37 
это не в языке, дурашка, это - в головах.
В процессоре нет никакого alloc, представляешь - вообще.

А проблема именно тем и вызвана что новое альтернативно одаренное поколение полезло теребонькать то что не следовало трогать - затобезопастным способом.

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


Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

34. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Аноним (-), 24-Янв-24, 12:43 
Да, да, это все новое "новое альтернативно одаренное поколение"
А кто писал шикарнейший код типа Dirty COW (CVE-2016-5195) которая жила с ядра 2.6.22?
А кто выпрограммировал sock_sendpage (CVE-2009-2692) который жил с 2001 по 2009?

В 2001 поколение смузихлебов, наверное, только в школу ходило.
А все эти кучи наваливали те самые диды, которые сейчас на это самое поколение бухтят.

Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –2 +/–
Сообщение от Аноним (20), 24-Янв-24, 13:26 
> А кто писал шикарнейший код типа Dirty COW (CVE-2016-5195) которая жила с ядра 2.6.22?
> А кто выпрограммировал sock_sendpage (CVE-2009-2692) который жил с 2001 по 2009?

Ахахахах, а ты вообще ничего не написал, ахахаха

Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (46), 24-Янв-24, 13:43 
А где ваши доказательства? (с)
Без пруфов это просто газификация лужи, что в принципе от лиютеля дыряшки и ожидалось)
Но оправдывать кал-лег бракоделов это у вас принято, как я понял.
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +2 +/–
Сообщение от Аноним (53), 24-Янв-24, 13:53 
Как говорят це-разработчики, "от всех этих дыр нам же только луДше!!1"
Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +3 +/–
Сообщение от Аноним (-), 24-Янв-24, 14:17 
Так правильно говорят!
Чем запутанее код и чем больше там непонятных багов - тем меньше шансов, что такого уволят.
Но даже если и уворят, то он найдет себе такой же проект написанный через одно место и будет сидеть на его поддержке годами.

Ты почитай на чем должны зарабытывать ГНУтики, согластно манифесту коммуняки столмана.
Правильно "на поддержке".
А чтобы поддержка и денюжка не закончились, то баги тоже не должны заканчиваться.

Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Аноним (-), 24-Янв-24, 12:48 
> это не в языке, дурашка, это - в головах.

Полностью согласен!
В головах у сишников, очевидно, опилки. Тк на протяжении 30-40 лет делать одни и те же ошибки...
Это надо явно обладать альтрнативным мышлением.

К сожалению целое поколение (а то и два) таких альтернативно одаренных сейчас сидит и пишут системы, от которых требуется максимальная надежность.
Но хуже того - они противодействуют любым попыткам как-то изменить ситуацию - тк в этом случае все их знания о 193 Undefined Behavior в C99 становятся ненужными и они могут идти работать дворниками.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

50. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Аноним (53), 24-Янв-24, 13:51 
> в этом случае все их знания о 193 Undefined Behavior в C99 становятся ненужными

А были ли знания? 99% сишников про UB не задумываются. Если программа не падает на его компе и его входных данных, то она считается стабильной.

Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Аноним (57), 24-Янв-24, 13:59 
Я тебе сейчас тайну открою. 99% сишников пох, даже если падает. И не только сишников, потому что иди нах, задачу решает. Тратить время на нештатные случаи и маловероятные ситуации стоит только когда это является проблемой.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 24-Янв-24, 14:22 
Отличное описание типи-кал СИ разработки.
Сначала зачем "Тратить время на нештатные случаи и маловероятные ситуации", а потом:
- у нас хартблид у половины интернета
- почти все андроид телефоны оказывают дырявыми
- машинки тойоты разгоняются сами по себе и убивают людей

Имеено поэтому такой подход должен помереть (вместе с бракоделами)

Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Аноним (20), 24-Янв-24, 14:33 
> Имеено поэтому такой подход должен помереть (вместе с бракоделами)

И кто останутся? Один ты, ничего не написавший?

Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (53), 24-Янв-24, 14:39 
Повторюсь, чем писать дырявый код, лучше не писать код вообще.
Поэтому, если удалить всех сишников (например, переквалифицировать в дворники), мир станет лучше.
Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 24-Янв-24, 14:44 
Свято место пусто не бывает)
Как сказал Линус - мы седые и старые, надо готовить молодеж на замену.
И добавил раст в ядро.
Вот новое поколение и будет писать.

> Один ты, ничего не написавший?

То что я написал уже 10 лет работает, так что мне есть чем гордиться.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

75. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (75), 24-Янв-24, 15:19 
Коллега, гордыня до бобра еще никого не довела. Начиная с прегордого денницы. Пустое это!
Лучше смотреть на это с радостью о том, что соделанное с Вашей помощью приносит пользу. Разница в пропасть. Попробуйте, почувствуете положительную динамику!
Ответить | Правка | Наверх | Cообщить модератору

82. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 24-Янв-24, 15:50 
Так я горжусь, что пол ляма народу ежедневно пользуются)
И это упрощает им жизнь, освобождает время на полезные делала - с детьми посидеть, кино посмотреть, на свидание сходить)
Я полностью понимаю, что это не лучший код в мире, так что без гордыни, но как говорится "это немного, но честная работа"
Ответить | Правка | Наверх | Cообщить модератору

92. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (20), 24-Янв-24, 16:44 
Плин, ну ты вспомнил. Я, до того как переехал в Европу, в России сменил больше 10 фирм. И в двух последних моим софтом до сих пор пользуются каждый день 24/7, который экономит компании деньги на коммерческих альтернативах. И да пользуются им дохера народу, кто является их клиентами, даже не подозревая об этом. Но я про такое говно даже не вспоминаю и не горжусь
Ответить | Правка | Наверх | Cообщить модератору

98. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 24-Янв-24, 17:03 
Ну не гордись) Я ж тебя не заставляю.
Просто когда из этих людей есть например наса или церн - то уже повод.
Ответить | Правка | Наверх | Cообщить модератору

95. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (75), 24-Янв-24, 17:00 
>Так я горжусь
>так что без гордыни

Не то чтобы я задроttством каким занимаюсь и к словам придираюсь, но на самом деле вопрос действительно важный. Когда-то тоже много чем гордился. Считал себя нереально вумным, як вутка и вот это все.
Но к счастью Господь не оставил и вразумил.
Теперь, чтобы я не делал, делаю как для Бога и с пониманием, что сам по себе лишь инструмент в Его руках, реализующий Его волю. Являясь при этом лишь сосудом всякой нечистоты.
Лучше не дожидаться жесткого вразумления.

Вопрос в отношении и восприятии себя и своего труда. Что основа, а что следствие.

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

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

103. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 24-Янв-24, 17:34 
Не, сорри.
У меня выдуманные невидимые друзья закончились еще в детстве.

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

Ответить | Правка | Наверх | Cообщить модератору

111. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (75), 24-Янв-24, 17:56 
Здесь как Вам будет угодно. Просто из собственного опыта рекомендовал.
Недавно узнал, что и друзей кроме Бога то нет. все имеют свою цену. Кто в денежном эквиваленте а кто и в иных единицах.

Догматическое представление Вы обрисовали неверно. Но в эти дискурсы вдаваться тут не будем. Просто почитайте, при случае источники.

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

Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Серб (ok), 24-Янв-24, 15:23 
> Как сказал Линус - мы седые и старые, надо готовить молодеж на замену.
> И добавил раст в ядро.
> Вот новое поколение и будет писать.

Только вряд ли на rust.

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

1) или сделают rust нормальным языком (что вряд ли, тяжко существующие решения с необходимыми требованиями связать)

2) или начнут использовать существующие наработки в ядре.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

56. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –1 +/–
Сообщение от нах. (?), 24-Янв-24, 13:58 
> К сожалению целое поколение (а то и два) таких альтернативно одаренных сейчас сидит и пишут системы

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

> Но хуже того - они противодействуют любым попыткам как-то изменить ситуацию

потому что пока что попытки сводятся к "давайте заставим их писать как НАМ хочется". От тех кто не умеет ничего кроме coc.md и мертворожденных переписываний того что в переписывании не нуждалось.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

63. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –2 +/–
Сообщение от Аноним (-), 24-Янв-24, 14:33 
> ну так ты-то ничего кроме комментов на опеннете не умеешь... а ресдох, написанный "правильным" поколением - почему-то сдох. Что ж ето деется - никому, оказывается, даром не нужна безопастная ось? Попробуй приплачивать?

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

> потому что пока что попытки сводятся к "давайте заставим их писать как НАМ хочется".

Да, именно так.
Если они настолько тупы, что за 30 лет не смогли писать без ошибок памяти, то придется заставлять.

> От тех кто не умеет ничего кроме coc.md и мертворожденных переписываний того что в переписывании не нуждалось.

Жалкие оправдания криворуких бракоделов)
Если аргументы закончились сведи все к COC.md
А учитывая что он есть в ядре docs.kernel.org/process/code-of-conduct.html, фряхе freebsd.org/internal/code-of-conduct/ или даже node-которая-js github.com/nodejs/admin/blob/HEAD/CODE_OF_CONDUCT.md
То приходим к неутешимому выводу - для успешности проекта оно необходимо.
Ну чтобы затыкать рот всякому невоспитанному б-лу.

Ответить | Правка | Наверх | Cообщить модератору

88. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Ivan_83 (ok), 24-Янв-24, 16:20 
Я вам повторю, поскольку до вас никак не доходит.

30 лет назад была куча безопасных языков, и 20 лет назад тоже.
Я обожал Visual Basic, целиком и полностью супер язык, супер IDE, супер справка.
Была только одна проблема: или ты пишешь на С или оно работает медленно и весит много. А проги тогда распространялись дискетами.
Иногда тяжёлые вычисления выносили в DLL на С а гуй оставляли на чём то более высокоуровневом.

Этот ваш раст в те времена даже скомпелячить нельзя было, ресурсов бы не хватило.
И пользоватся им тоже было бы не возможно - он дико тормозной, ждать пока он соберёт хелло ворлд за 20 минут никто бы не стал.
Вся безопасность раста свелась бы к тому, что код написанный на нём даже не собрался а если и собрался то не запустился :)

И сейчас, не смотря на все кудахтанья, успехи раста сводятся к порче отдельных С/С++ проектов, которые теперь и собирать трудно и поддерживать не возможно из за смешения языков.
Всё что делают растоманы - это греют воздух и сжирают производительность.
Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке.
В плане поддержки это полная абракадабра.

Фишка программ на С в том что они быстро и везде собираются, синтаксис понятен любому идиоту, и ошибки относительно легко исправляются, особенно современными инструментами.
У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис.

Ответить | Правка | Наверх | Cообщить модератору

94. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Советский инженер (ok), 24-Янв-24, 16:58 
>синтаксис понятен любому идиоту

время идиотов в кодинге прошло

>ошибки относительно легко исправляются, особенно современными инструментами

все упоротые сишники все время рассказывают про эти современные инструменты, но элементарного fuzz testing так и не осилили на таком важном проекте !!!

так что ты, прежде чем учить жизни растоманов, научись этими современными инструментами пользоваться, а не в коментах про них рассказывать.

Ответить | Правка | Наверх | Cообщить модератору

141. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Ivan_83 (ok), 24-Янв-24, 20:18 
> время идиотов в кодинге прошло

О нет, как раз новое поколение пришло :)
Просто когда мы бунтовали то переписывали библиотеки и проекты с нуля, а теперь мода переписывать на модных языках.


> все упоротые сишники все время рассказывают про эти современные инструменты, но элементарного fuzz testing так и не осилили на таком важном проекте !!!

Это ваша оценка.
Моя оценка отличается: я не боюсь ошибок в программах и то что программы падают.
Там где критично - пусть производитель делает +1 резервирование, остальное перезагрузят/перезапустят пользователи.

Ответить | Правка | Наверх | Cообщить модератору

151. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 24-Янв-24, 23:23 
Предположим, пользователи перезапустят.
А что делать с уязвимостями типа heartbleed?
Когда в один момент выясняется, что половина шифорвания была уязвима?
Не думаю, что вы бы обрадовались "о, прочитать мою почту, майору, провайдеру и вообще кому угодно стало проще".

Или например удаленноен получение рута через уязвимость браузера, хорг сервера и тд.
Мне было бы неприятно, если бы по моему компу шарился кто попало.

Ответить | Правка | Наверх | Cообщить модератору

162. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Ivan_83 (ok), 25-Янв-24, 01:09 
Ничего, всё исправят в своё время, как обычно.

> Не думаю, что вы бы обрадовались "о, прочитать мою почту, майору, провайдеру и вообще кому угодно стало проще".

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


> Или например удаленноен получение рута через уязвимость браузера, хорг сервера и тд.

И что?
Перезагрузить, переустановить.
Всё как обычно.

Ответить | Правка | Наверх | Cообщить модератору

99. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Аноним (-), 24-Янв-24, 17:10 
Вот вроде говорите правильные вещи, но выводы из них делаете... мама родная...
Да 30 лет назад сишка захватила мир, потому что можно было быстро наыдлокодить программу.
Уже тогда была ада, но просто на ней писать было сложнее, а идиотов оказалось больше.
Да 20 лет назад не было таких мощностей как сейчас.
Ну и проекты были маленькие - сравните ядро тогда и сейчас.

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

Сишники не в состоянии следить за памятью в больших проектах.
Да в общем-то никто не в состоянии, просто только сишники упорно пытаются доказать всем, что именно они могут и как всегда жиденько...
Они обязательно где-то накосячат, хотя правила до тупости просты:
- один раз память выделил - один раз очистил, не больше и не меньше
- за пределами выделенного не читай
- за пределы выделенного не пиши
И всё! Просто сложность проекта не позволяет это всё удержать в голове.
Эта очередная новость - тому доказательство.

> Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке.

Невозможно свести ноль в ноль. У си никакого прогресса за 20 лет не было.
У плюсов был и довольно большой. Но не у дыряшки.

> и ошибки относительно легко исправляются

Ошибки нужно не делать, а не сначала делать, а потом легко исправлять.
Плюс посмотри по сколько лет эти ошибки живут в проектах. Годами! И их никто не замечает.

> У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис.

Раст долго собирается как раз потому, что он делает куча проверок в compile-time, в отличие от сишки.
Но в рантайме он сравнимо быстр. И это уже не вопрос, это утверждение.

А несъедобен синтаксис у него только для закостенелых мозгов.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

143. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –1 +/–
Сообщение от Ivan_83 (ok), 24-Янв-24, 21:04 
От того что у вас мобила лишний раз перезагрузится или приложение в ней - ничего страшного не случится.
Вот и вся цена ошибок.
Не надо раздувать из мухи слона.


> Невозможно свести ноль в ноль. У си никакого прогресса за 20 лет не было. У плюсов был и довольно большой. Но не у дыряшки.

Я вообще то про прогресс вычислительной мощности который раст помножает на ноль.
Самому С развиватся особо и не надо, С++ прекрасный пример того как делать нельзя. Но вот раст упорно делает как С++ при этом заявляя себя заменой всему.


> Плюс посмотри по сколько лет эти ошибки живут в проектах. Годами! И их никто не замечает.

И никому не мешают, так бы нашёлся кто то кто сам починил или заплатил.


> А несъедобен синтаксис у него только для закостенелых мозгов.

Есть множество примеров с обычными языками и письменностями.
Раст это азиатские иероглифы, против С - простого и лаконичного как английский.

Ответить | Правка | Наверх | Cообщить модератору

155. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 24-Янв-24, 23:26 
У вас через браузер, через вьювер картинок или через пдф-просмоторщик уведут пароли, взломают банкинг, взломают сервак через специально оформленный пакет.
Вот и вся цена ошибок)))

> Я вообще то про прогресс вычислительной мощности который раст помножает на ноль.

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

> Самому С развиватся особо и не надо

Ну-ну. А когда в си появятся... напр. нормальные enum, а не убогая обертка над числом? Или associated value?
Или это излишество, типа деды и без них прожили и нам не нужно?
Вообще, тот кто не развивается, то в итоге вымирает.

> Раст это азиатские иероглифы, против С - простого и лаконичного как английский.

Уверен на 95% что вы или ничего не писали на расте, или писали какой-то hello world.

> простого и лаконичного как английский

Простите, но это сравнение просто смешно))
Да, английский может проще чем иероглифы, но простым и лаконичным его уж точно назвать нельзя.
Местами он существенно сложнее, чем напр. японский.

Ответить | Правка | Наверх | Cообщить модератору

164. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Ivan_83 (ok), 25-Янв-24, 01:18 
> У вас через браузер, через вьювер картинок или через пдф-просмоторщик уведут пароли, взломают банкинг, взломают сервак через специально оформленный пакет.

Мой банковский счёт не стоит таких усилий, будем честны, и ваш тоже :)


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

Да да, и все владения объектами, все синхронизации доступа они тоже бесплатные.


> Несколько землекопов, которым ну вот все хочется компилировать самим - никого не интересуют.

Так вы щас топите против опенсорца, потому что возможность самостоятельно собрать один из основных критериев свободы.
А гниль настолько тормозная что ещё немного и сборка будет проходить только у бигкорпов на топ500 компах.


> А когда в си появятся... напр. нормальные enum, а не убогая обертка над числом? Или associated value?

Зачем?
Если вам нужен сахар - используйте другие языки, С для минималистов.


> Вообще, тот кто не развивается, то в итоге вымирает.

Расскажите это обилию растительности и живности вокруг вас.
Есть масса замечательных стабильных форм, которые лишь незначитально видоизменяются со временем для адаптации к изменениям окружающей среды.
Если бы всё в природе развивалось как кресты или гниль то осталось бы полтора огромных мутанта размером с материк. В общем можете посмотреть на азиатские иероглифы чтобы понять куда вы идёте, там тоже на любой чих свой иероглиф, они обмазались синтаксическим сахаром почти на 100%.


Ответить | Правка | Наверх | Cообщить модератору

183. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 25-Янв-24, 11:04 
> Мой банковский счёт не стоит таких усилий, будем честны, и ваш тоже :)

Согласился бы, если бы усилия вообще были нужны.
Эксплойт может работать в автоматическом режиме, и ему будт пофиг у вас на карточке 100 рублей или 100 тысяч.

> Так вы щас топите против опенсорца, потому что возможность самостоятельно собрать один из основных критериев свободы.

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

> Если вам нужен сахар - используйте другие языки, С для минималистов.

Так пусть минималисты пишут свое ядро только на СИ, а мы будем писать свое ядро на СИ  и Rust.
Раз вы такие крутые то сделать форк и поддерживать самим вы точно справитесь)

> Расскажите это обилию растительности и живности вокруг вас.

Именно поэтому появился Раст, тк если бы вокруг был только СИ - это было бы очень глючно и печально, прям как сейчас.
А поп поводу сахара - на него жалуются только неосиляторы, которые больше 10 значков в голове держать не могут.
Отсюда и постоянные уязвимости в СИ коде.

Ответить | Правка | Наверх | Cообщить модератору

199. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Ivan_83 (ok), 25-Янв-24, 20:53 
> Эксплойт может работать в автоматическом режиме, и ему будт пофиг у вас на карточке 100 рублей или 100 тысяч.

Это так не работает в банками, только щиткойнами.
Там нужна цепочка чтобы по быстрому перевести и вывести в нал, ради 100 руб никто возится не будет.
И у меня банки вечно требуют СМС при любом переводе за пределы своих счетов в одном банке.


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

Вы так договоритесь что вам тоже чтонибудь IRL отрежут до уровня невыносимого существования и скажут: нуачо, так же тоже жить можно. Например в бараке без отопления и с удобствами на улице.


> Так пусть минималисты пишут свое ядро только на СИ, а мы будем писать свое ядро на СИ  и Rust.

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


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

У меня в жизни полно других и проблем и увлечений чтобы забивать голову помоями которые каждый день изобретает очередной фрик.
Вы упорно не хотите смотреть вокруг себя и думать, иначе бы давно поняли к чему приходит всё что содержит столько сахара.

Ответить | Правка | Наверх | Cообщить модератору

176. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Совершенно другой аноним (?), 25-Янв-24, 09:56 
> Да, английский может проще чем иероглифы, но простым и лаконичным его уж точно назвать нельзя.
> Местами он существенно сложнее, чем напр. японский.

Прошу прощения, так-сказать на правах лингвиста, боюсь, что японский ни в чём не проще английского. Вот уж где, на самом деле, наркомания во все поля. Насколько я понимаю, даже китайский попроще будет. Для затравки - https://habr.com/ru/articles/673446/. Там ещё есть две части с продолжением, если вдруг станет интересно: https://habr.com/ru/articles/678716/ и https://habr.com/ru/articles/683820/

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

190. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 25-Янв-24, 12:02 
Прошу прощения, но на правах учащего японский и знающего английский на уровне средний+, все равно считаю, что МЕСТАМИ японской ДЛЯ МЕНЯ проще чем английский. Напр. глаголами.


Ответить | Правка | Наверх | Cообщить модератору

192. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Совершенно другой аноним (?), 25-Янв-24, 13:05 
Ну вроде как идея была правильная - все глаголы заканчиваются на "る", но потом, внезапно оказалость что это не так, и есть глаголы, условно заканчивающиеся на "う", потом там ещё один вид глаголов есть, если помню правильно. А потом ещё оказалось, что окончания глаголов меняется, причём очень сильно по-разному в зависимости от контекста и времени (всякие там った дорисовываются, а предыдущие окончания отбрасываются). Так-что позвольте с Вами не согласиться - там и с глаголами полный порядок.
Ответить | Правка | Наверх | Cообщить модератору

156. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от жабабыдлокодер (ok), 24-Янв-24, 23:40 
Мобила лишний раз перезагрузится, томограф неправильные данные передаст, искусственная почка зависнет, автопилот на середине маневра отключится. С точки зрения человечества - человечество не заметит, да.
Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

101. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 24-Янв-24, 17:20 
> 30 лет назад была куча безопасных языков, и 20 лет назад тоже.

Да они и сейчас есть, Ада например (и особенно Spark Pro).
Но, к сожалению, в ядро попала отвратительная дыряшка, которая теперь множит дыряшки для пользователей.

> Этот ваш раст в те времена даже скомпелячить нельзя было, ресурсов бы не хватило.

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

> И сейчас, не смотря на все кудахтанья, успехи раста сводятся к порче отдельных С/С++ проектов, которые теперь и собирать трудно и поддерживать не возможно из за смешения языков.

Максимально бредовое утверждение. Тут уже кидали ссылки и на андроид. и на драйвер для М1 который прошел сертификацию кроноса, и на кучи утилит (от амазона, RustVMM, до ядра Maestro)

> Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке.

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

> В плане поддержки это полная абракадабра.

Просто так скажи "я неосилятор, у меня мозг усох и нового я освоить не могу".

> Фишка программ на С в том что они быстро и везде собираются, синтаксис понятен любому идиоту, и ошибки относительно легко исправляются, особенно современными инструментами.

Хахахаха, кажется у тебя упал красный нос 🔴, возьми пожалуйста.
Уязвимости живут в ядре по 5-10-15 лет. В овнопроектах типа хорг - так вообще 35.
И где эти ваши инструменты?

> У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис.

Нет, нет и нет)
Безопасность там именно такая как обещали.
Скорость там сравнимая, можешь просветиться на benchmarksgame
То что ты не моешь осилисть синтакс, так ты наверное просто старый.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

161. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Ivan_83 (ok), 25-Янв-24, 01:04 
> Можно и на улицу в кустики бегать, но люди предпочитают нормальный санузел.

Так проблема в том, что вы этот санузел пытаетесь изуродовать со словами:
- как бы мимо никто не пописал, потому надо писать сидя, вставляя катетор
- как бы микробы не размножились потому надо перед использованием 10 дней проводить дезинфекцию а после использования нужно сносить и перестраивать заново


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

Проблема только в том, что такие лезут к тем кого и так всё устраивает и доводят до неудовлетворительного состояния.


> Уязвимости живут в ядре по 5-10-15 лет. В овнопроектах типа хорг - так вообще 35.

И кому они помешали?


> Скорость там сравнимая, можешь просветиться на benchmarksgame

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

Ответить | Правка | Наверх | Cообщить модератору

110. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –2 +/–
Сообщение от Аноним (110), 24-Янв-24, 17:55 
Кто о чем, а вшывый о расте.
А ведь в коменте на который ты отвечал ни слова о расте.

И да, один из безопасных языков это Ада.
И Ада даже есть в гцц.
Но диды упорно продолжают выходить за границы буфера.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

114. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (106), 24-Янв-24, 17:56 
Можно было просто написать "раньше было лучше, а теперь гогно, хотим быть идиотами" и получилось бы то же самое, но без балабольства.
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

160. Скрыто модератором  +/–
Сообщение от Аноним (-), 24-Янв-24, 23:59 
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

165. Скрыто модератором  +/–
Сообщение от Ivan_83 (ok), 25-Янв-24, 01:49 
Ответить | Правка | Наверх | Cообщить модератору

185. Скрыто модератором  +/–
Сообщение от Аноним (-), 25-Янв-24, 11:27 
Ответить | Правка | Наверх | Cообщить модератору

202. Скрыто модератором  +/–
Сообщение от Ivan_83 (ok), 25-Янв-24, 21:37 
Ответить | Правка | Наверх | Cообщить модератору

204. Скрыто модератором  +/–
Сообщение от n00by (ok), 26-Янв-24, 08:03 
Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

175. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –1 +/–
Сообщение от Аноним (175), 25-Янв-24, 09:31 
>синтаксис понятен любому идиоту

ага особенно с void (*functionPtr)(void);
и всякие && || ^ & | << >>

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

181. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +2 +/–
Сообщение от Совершенно другой аноним (?), 25-Янв-24, 10:42 
Но согласитесь, у Rust с этим гораздо хуже..

fn longest<'a, 'b : 'a>(x: &'a String, y: &'b String) -> &'a String {
...
}

Почему-то сразу вспоминается Говард Лавкрафт с его "Пх'нглуи мглв'нафх Ктулху Р'льех вгах'нагл фхтагн".

Ответить | Правка | Наверх | Cообщить модератору

189. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Аноним (-), 25-Янв-24, 11:56 
Добавился символ ', выкинули символ ^.
Не вижу ничего сложного - очень похоже int (^)(char, float)
К такому привыкаешь за примерно недельку ленивого программинга на раст по вечерам.

В си тоже хватает такого
#define container_of(ptr, type, member) ({                      \
        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
        (type *)( (char *)__mptr - offsetof(type,member) );})

Ответить | Правка | Наверх | Cообщить модератору

191. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от Совершенно другой аноним (?), 25-Янв-24, 12:20 
> Добавился символ ', выкинули символ ^.
> Не вижу ничего сложного - очень похоже int (^)(char, float)

не скажите. Когда два подряд спец-символа, как-то глаз спотыкается и выглядит не очень как по мне. А так-то да - ко всему можно привыкнуть и на Brainfuck-е писать, если сильно прижмёт.

> В си тоже хватает такого
> #define container_of(ptr, type, member) ({                      \
>        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
>        (type *)( (char *)__mptr - offsetof(type,member) );})

В Вашем примере как-раз такого и нет, но есть обилие скобок.

Ответить | Правка | Наверх | Cообщить модератору

195. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/–
Сообщение от n00by (ok), 25-Янв-24, 16:39 
> Когда два подряд спец-символа, как-то глаз спотыкается и выглядит не
> очень как по мне.

Это про одинарную кавычку? Она ж во многих языках требует закрывающей пары. Потому и не читается.

Ответить | Правка | Наверх | Cообщить модератору

200. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Ivan_83 (ok), 25-Янв-24, 21:04 
Таких макросов полторы штуки и нужны они крайне редко, если именно по нужде а не потому что ты пишешь "криптокод" ибо думаешь так же странно.

Указанный вами макрос и даже typeof() я не использовал вообще никогда - не было необходимости.
Самое извращенское было:

#ifndef offsetof /* offsetof struct field */
#    define offsetof(__type, __field)                \
        ((size_t)((const volatile void*)&((__type*)0)->__field))
#endif

#define MEMCPY_STRUCT_FIELD(__dst, __sdata, __stype, __sfield)        \
    memcpy((__dst),                            \
        (((const char*)(__sdata)) + offsetof(__stype, __sfield)),    \
        fieldsetof(__stype, __sfield))

И даже это только потому что я хотел чтобы код на всяких не х86 не падал, иначе можно было просто скастовать и пофиг что оно там может быть не выровнено.

Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

182. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –2 +/–
Сообщение от Bottle (?), 25-Янв-24, 11:01 
>Фишка программ на С в том что они быстро и везде собираются

Ахахаха, расскажи это разработчикам ядра Линукс. Особенно Инго Молнару, который целый год потратил на оптимизацию заголовочных файлов ядра, чтобы оно быстрее собиралось.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

198. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/–
Сообщение от Аноним (198), 25-Янв-24, 18:40 
Растоманам лучше помалкивать о скорости сборки, а то выйдет неудобно :)
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру