The OpenNET Project / Index page

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

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


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

Оглавление

Lunatik - инструментарий для создания в ядре Linux обработчиков на языке Lua, opennews (?), 22-Апр-24, (0) [смотреть все]

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


10. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  –2 +/–
Сообщение от Fracta1L (ok), 22-Апр-24, 09:39 
Видимо, с притоком свежих программистов на сишке всё очень плохо.
Ответить | Правка | Наверх | Cообщить модератору

12. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  –1 +/–
Сообщение от KroTozeR (ok), 22-Апр-24, 09:44 
Ну, это ж больно, это ж думать надо.
Ответить | Правка | Наверх | Cообщить модератору

20. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от Аноним (20), 22-Апр-24, 10:09 
Как случайно очередное rce в ядро протащить?
Ответить | Правка | Наверх | Cообщить модератору

22. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 10:13 
Ну-ну.
Чтобы заставить работать любой нормальный язык в связке с сишкой, думать нужно на порядок больше, чем велосипедить очередной сплит строк на чистой сишке.
Тут скорее вопросы, хотя, это даже не вопросы, к сишникам - "почему они не могут осилить ничего кроме сишки" и "когда перестанут выходить за границы буфера"?
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

28. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Ivan_83 (ok), 22-Апр-24, 10:20 
Вот LUA можем.
C+LUA и больше особо ничего не надо.
Даже make системы есть на LUA.
Так что у нас всё самодостаточно.
Ответить | Правка | Наверх | Cообщить модератору

36. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от KroTozeR (ok), 22-Апр-24, 10:25 
Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока такое умеет только Zig, но это не значит, что им всё ограничится. Там вообще ничего кроме самого ЯП и его окружения не нужно.
Ответить | Правка | Наверх | Cообщить модератору

46. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Ivan_83 (ok), 22-Апр-24, 10:55 
Не уверен что правильно понял "отдать ЯП право управления компилятором".

Помнится quick basic, Visual Basic - вполне себе и ЯП и компилятор были в одном флаконе что называется. У последнего ещё и code style с принудительным автоформатером был, потому даже самые "одарённые" писали так что при чтении кровь из глаз не текла ручьём.

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

62. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от KroTozeR (ok), 22-Апр-24, 11:31 
Все операции, вызываемые обычно через системы сборки, умещаются в исходник на Zig с применением конструкций языка. В такой ситуации CMake — попросту ненужный бесполезный громоздкий наворот.
Ответить | Правка | Наверх | Cообщить модератору

57. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от n00by (ok), 22-Апр-24, 11:19 
> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока
> такое умеет только Zig

В смысле, Nemerle помер?

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

61. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от KroTozeR (ok), 22-Апр-24, 11:28 
А он ещё жив? К тому же, .Net — это же никак не про фундаменталку.
Ответить | Правка | Наверх | Cообщить модератору

67. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от n00by (ok), 22-Апр-24, 11:39 
Не знаю, жив ли, но появился задолго до Zig. Ну и на .Net вполне написали совершенно безопасную Microsoft Singularity. Потом, правда, отправили в музей и теперь пишут другую безопасную ОС.
Ответить | Правка | Наверх | Cообщить модератору

90. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (65), 22-Апр-24, 13:45 
Mono в ядро? Зато сколько сразу языков!
Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

168. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (168), 23-Апр-24, 12:35 
>> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока
>> такое умеет только Zig
> В смысле, Nemerle помер?

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

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

183. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от n00by (ok), 23-Апр-24, 15:31 
>>> Можно просто отдать ЯП право управления компилятором и задачу прекомпилятора. Сейчас пока
>>> такое умеет только Zig
>> В смысле, Nemerle помер?
> Нельзя убить то что никогда не жило. Эта штука всегда была где-то
> рядом с singularity, микроядрами и прочими концепт-карами. Много вы концепт каров
> на улице видели?

Я не понял, к какому из языков это относится.


Разработка языка Nemerle началась в 2003 году в университете Вроцлава (Польша).
...
12 марта 2010 года была выпущена первая бета-версия компилятора языка
...
С июня 2012 года команда разработчиков Nemerle стала частью компании JetBrains, которая займётся дальнейшей разработкой и поддержкой языка.
...
Выпуск     1.2.547.0 (01.09.2017)


Zig

Появился в     2015

Выпуск     0.11.0 (4 августа 2023)

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

37. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от KroTozeR (ok), 22-Апр-24, 10:31 
Зачем для задач Си применять что-то кроме него, если самого Си хватает с головой? Поделие, которое очень плохо вылизано под такие задачи не должно иметь приоритета только за счёт "новизны". Понятно, что у самого Си есть проблемы, которые в разной степени купируются проектами GoLang, Rust, Zig, Num  и т.п., но когда предлагают замещать Си Python-ом, это уже какой-то испанский стыд...
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

97. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от Аноним (126), 22-Апр-24, 14:36 
>почему они не могут осилить ничего кроме сишки

А зачем еще что-то кроме сижки? Си это идеальный язык, минималистичный
Но с большой силой приходит и большая ответсвенность
То что некоторые допускают уязвимости в своих программах, сугубо ответсвенность писарей этих самых программ
Ей богу, надоело уже слушать эти все колкости в сторону языка

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

101. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 14:48 
> А зачем еще что-то кроме сижки?

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

> Си это идеальный язык, минималистичный

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

> Но с большой силой приходит и большая ответсвенность

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

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

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


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

105. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от Аноним (105), 22-Апр-24, 15:11 
> С кучей непродуманных мест сделаных "на отвались", т.е на "нам решать лениво, пусть там компилятор сам разберется".

Это ты точно про Си, а не про раст?

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

А язык тут причем? Все вопросы к автору компиляторов, почему md5 финального бинаря отличается

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

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

> За 50 лет адепты так и не смогли не портить память.

Растаманы тоже портят, просто из-под раста этого не видно, см. первую цитату про "лениво решать, пусть компилятор что-то там"

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

Си - это такой... как сказать... высокоуровненый ассемблер что ли. А асме тоже нету никакой защиты (но она может быть на уровне микрокода и/или архитектуры). Тебя не парит, что в asm нет никакой защиты? Ну вот и в Си так же

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

117. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (117), 22-Апр-24, 16:50 
> Это ты точно про Си, а не про раст?

Конечно. Скажи спасибо комитету за UB и ID.

> А язык тут причем? Все вопросы к автору компиляторов, почему md5 финального бинаря отличается

Так разрабы компилятора все делали по "стандарту". Ну, т.е. по тому куску ###, которое по традиции называют стандартом. И если там написано - "а мы хз, делайте как хотите", то они делают как хотят.

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

en.cppreference.com/w/c/compiler_support
Покажи, пожалуйста, хоть один, который реализует стандарт полностью. Т.е. без "no" и "partial".
Вот только не начинай что "это не такая важная штука", "они не обязаны" и тд

> Си - это такой... как сказать... высокоуровненый ассемблер что ли.

Абсолютно согласен. Вот только сейчас писать на асме больше пары страниц кода уже нет смысла - в 99% случаев компилятор оптимизирует лучше. А оставшийся 1% увидишь в профайлере и перепишешь ручками.
А на сишке пишут проекты на миллионы строк кода. И понятно что оно будет как в асме - дыра на дыре.

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

154. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (154), 23-Апр-24, 01:37 
> Скажи спасибо комитету за UB и ID.

Спасибо им, что есть стандарт. У некоторых и такого нету, а потому там любое поведение потенциальное UB, если не сегодня, то при следущем обновлении.

> Покажи, пожалуйста, хоть один, который реализует стандарт полностью.

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

> Си - это такой... как сказать... высокоуровненый ассемблер что ли.

C (API) - это дефакто стандарт совместимости между программами на любых языках, включая те, которым без году неделя, но нос до небес, ведь хозяин из M$ их похвалил и кость бросил.


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

109. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (105), 22-Апр-24, 15:28 
> С кодом, который на разных версиях компиляторов выдает разные результаты.

Можно пример?

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

116. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  –1 +/–
Сообщение от Аноним (117), 22-Апр-24, 16:40 
Да легко - берешь любой код с сишным UB или implementation defined и приехали.

int main()
{
    int i=7;
    i = i++ * i++;
    return i;
}

По ссылке godbolt.org/z/s3Kve4chY 6 компиляторов и целых 3 (ТРИ) разных результата.
GCC 4.8 - 56, GCC 4.7 - 51.
И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и то, не все компиляторы.

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

119. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (105), 22-Апр-24, 17:15 
Ля, я думал там что-то настоящее, то что имеет место быть в реальном коде и даёт разный результат.
Ну ты ж сам написал ответ - UB, а значит результат может быть любой, какие вопросы что он разный везде?  Лично кажется 56 - логичным, но это моё личное мнение

int i = 7;
i++ * i++;
1. пост-инкрементируем 7
2. умножаем 8 на 7

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

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

121. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  –1 +/–
Сообщение от Аноним (-), 22-Апр-24, 17:32 
> Ля, я думал там что-то настоящее, то что имеет место быть в реальном коде и даёт разный результат.

Вот тебе пример настоящего и вполне реального кода
opennet.ru/opennews/art.shtml?num=58612
"устранена уязвимость, позволяющая поднять свои привилегии в системе бла-бла"

Фикс выглядит так
-        else
+        else {
             free(to->button->xkb_acts);
+            to->button->xkb_acts = NULL;
+        }
gitlab.freedesktop.org/xorg/xserver/-/commit/0ba6d8c37071131a49790243cdac55392ecf71ec

Это происходит по причине того, что в дыряшке очень любят пихать UB куда надо и не надо
J.2:
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).

> Но в любом случае это UB и так писать нельзя.

Но пишут. Причем в реальном, много где используемом софте!

> Ты покажи нормальный код без UB и где результат разный на разных версиях компилятора

Ты лучше покажи мне программу на СИ без UB/IB/ID и тд))
Я уже молчу, что только в С99 как минимум 193 варианта UB.

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

123. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от Ivan_83 (ok), 22-Апр-24, 17:41 
То что вы показали это фикс для use-after-free, никак не UB.
Ответить | Правка | Наверх | Cообщить модератору

130. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 18:02 
> какие вопросы что он разный везде?

А... т.е. все ок, никаких проблем нет? Я правильно понял?

> Но в любом случае это UB и так писать нельзя.

Ахаха, а то что? Компилятор пальчиком погрозит?

> Ты покажи нормальный код без UB и где результат разный на разных версиях компилятора

Ты лучше покажи сишный код написанный без UB. Они же везде - в ядре, в иксах, в прикладном софте.

Вот тебе пример их x11 CVE-2023-43787. Signed integer overflow. Которые тоже UB.
Так что, так нельзя писать?))

И в ядре таких мест куча. Тут даже статейку написали lwn.net/Articles/511259 про то, что оптимизации ломают овнокод ядра, который опирается на поведение signed integer overflow.

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

132. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (105), 22-Апр-24, 18:09 
> Вот тебе пример их x11 CVE-2023-43787. Signed integer overflow. Которые тоже UB.
> Так что, так нельзя писать?))

Я не понимаю что ты пытаешься сказать, сорри.
То что в расте overflow проверяется всегда и нет возможности это отключить? Ну наверно, я хз. В Си нет - оверфлоу не проверяется самим языком, как и в ассемблере он не проверяется. Ну у тебя есть возможность его проверить самому. Хочешь - проверяй, хочешь - не проверяй.

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

136. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 18:22 
> Я не понимаю что ты пытаешься сказать, сорри.

Проблема не в том, проверяется он или нет.
А в том что поведение неопределенное.

> То что в расте overflow проверяется всегда и нет возможности это отключить?

Нет, в расте оно так:
- в дебаге будут проверки и ошибка checks for integer overflow that cause your program to panic at runtime if this behavior occurs.
- в релизе будет two’s complement wrapping.
Но! Поведение будет всегда одно и тоже.
doc.rust-lang.org/book/ch03-02-data-types.html

Нет у них UB в этом вопросе. Как и в других.
При этом если ты хочешь специфицировать другое поведение - то для этого есть функции wrapping_, overflowing_, saturating_ и checked_.

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

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

138. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (105), 22-Апр-24, 18:27 
> А для си у тебя получаются код, которые просто выдает разный результат.

потому что простота реализации и лаконичность :)

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

139. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 18:34 
>> А для си у тебя получаются код, которые просто выдает разный результат.
> потому что простота реализации и лаконичность :)

Бот что-то лютует. Хз чего он скрыл твой коммент...

"Простота реализации и лаконичность" это наверное круто.
Но это было актуально когда компьютеры были очень медленными.

А сейчас я бы предпочел cи2, с таким же синтаксисом, но с решением всех этих проблем, даже путем слома обратной совместимости. Пусть новый компилятор ругается на все эти места. Их тогда исправят при желании.


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

137. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 18:26 
> Я не понимаю что ты пытаешься сказать, сорри.

1. UB и прочие каки в 'стандарте' приводят к ошибкам
2. Такой код пишется в прод, включая ядро и кучу либ
3. Отслеживать и предотвращать такие ошибки не научились за пол века и повторяют их постоянно (новости можно читать каждые 2 недели)
4. Ошибки приводят к уязвимостям включая RCE
5. Без слома обратной совместимости исправить все недостатки невозможно, проще уже написать новый язык

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


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

151. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (151), 22-Апр-24, 23:54 
Если бы был такой безопасный язык, который ломал обратную совместимость с Си ровно в необходимом объёме. А его нет, так что многие берут Си-с-расширениями, берут плюсы и называют их удовлетворительными инструментами. Хотя перспективы... Страуструп после заявления АНБ про memory-safety назвал ситуацию чрезвычайной (current “emergency”) и... перевёл разговор на тему, что бывает много других видов безопасности, мда. C++ будущего - это замороженный язык.

Если назвать плюсы достаточно большим шагом вперёд, то всё равно Линус "C++ is a horrible language" Торвальдс и Бьёрн "C++ exceptions have been successfully used in [Linux] kernel code" Страуструп катастрофически расходятся во взглядах на ядро.

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

131. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 18:08 
Вот тебе без UB.
int main()
{
    int i=-42;
    i = i >> 5;
    return i;
}

Right-shifting a signed integer value which is negative is implementation-dependent.
Код, содержащий implementation-dependent - более чем валидный.
godbolt.org/z/dGnfPj7ad

GCC 11.3 - 254
MinGW GCC 11.3 - 4294967294

Вот такая вот прекрасная переносимость))
Причем по "стандарту" implementation-dependent может меняться от версии к версии.

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

141. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от n00by (ok), 22-Апр-24, 19:01 
Порадуете примером из жизни, где бы такое понадобилось? Что бы не считать за непонимание, как выполнять деление.
Ответить | Правка | Наверх | Cообщить модератору

198. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (196), 26-Апр-24, 09:44 
>Right-shifting a signed integer value which is negative is implementation-dependent.

И что из написанного здесь тебе не понятно?

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

120. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от Аноним (105), 22-Апр-24, 17:25 
> Да легко - берешь любой код с сишным UB или implementation defined и приехали.

Ясно, ссылку можно даже не открывать

> И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и то, не все компиляторы.

Именно, что по стандарту и результат соответствует стандарту, то есть - ваще ЛЮБОЙ.

А у меня тоже к тебе вопрос. Ты реально думаешь что вот этот пример выше это проблема? Ну просто когда ты инкрементируешь переменную и умножаешь ее на самому себя, еще раз инкрементируя. Какой результат ты сам то тут ожидаешь? И почему?

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

122. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 17:41 
Я выше скинул ссылку на реальную уязвимость из ХОрга.

> Именно, что по стандарту и результат соответствует стандарту, то есть - ваще ЛЮБОЙ.

СТАНДАРТ 1. Образец, к-рому должно соответствовать, удовлетворять что-н. по своим признакам, свойствам, качествам, а также документ, содержащий в себе соответствующие сведения
Если у тебя один и тот же код, дает разный результат просто при смене версии одного и того же компилятора, то это не стандарт.

"Стандарт СИ" это почти как Гост на колбасу вида "колбаса делается из мяса, может содержать добавки в виде сала, туал.бумаги или овна, в зависимости от желания компилятора рецепта - повара"
Не думаю что оно тебя бы сильно порадовало)

> А у меня тоже к тебе вопрос. Ты реально думаешь что вот этот пример выше это проблема?

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

> Какой результат ты сам то тут ожидаешь? И почему?

Любой. Главное одинаковый! Но зависящий от компиялтора, его версии, фазы луны, погоді на марсе и тд.
Потому что если твоя програма 99 раз считает верно, а в 100й отстреливает тебе пятую точку, то это просто какая-то фигня.

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

128. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (105), 22-Апр-24, 17:47 
Ок, напиши такой же код на расте и проверим на разных версия раста.

Хотя... давай я напишу на Си так, как ты бы написал на расте.

int i = 7;

i += 1;
i = i * i;

теперь везде одинаково? На всех версия gcc?

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

125. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +1 +/–
Сообщение от Аноним (105), 22-Апр-24, 17:43 
Ага, а в расте ваще нету префикс/постфикс инкремента. То есть ваще нету

Preincrement and postincrement (and the decrement equivalents), while convenient, are also fairly complex. They require knowledge of evaluation order, and often lead to subtle bugs and undefined behavior in C and C++. x = x + 1 or x += 1 is only slightly longer, but unambiguous.

Понятно в общем. То есть в расте не решили эту проблему, а просто убрали фичу. Как говорится, нет кода - нет багов

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

133. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 22-Апр-24, 18:12 
> То есть в расте не решили эту проблему, а просто убрали фичу.

А тут уже философский вопрос.
Добавить "фичу" и заодно сделать UB, который в общем случае позволяет компилятору во время оптимизации делать вообще что хочет - выкинуть эту ветку напр.
Или не добавлять фичу, зато сделать поведение однозначным.

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

135. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (105), 22-Апр-24, 18:21 
Кстати, я что сказать то хотел. Спасибо, что не грубишь, как большинство тут :) Было приятно подискуттировать :)
Ответить | Правка | Наверх | Cообщить модератору

177. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 23-Апр-24, 13:58 
> По ссылке godbolt.org/z/s3Kve4chY 6 компиляторов и целых 3 (ТРИ) разных результата.
> GCC 4.8 - 56, GCC 4.7 - 51.
> И ведь все по "стандарту" сделано, компиляторы только какие-то ворнинги сыпет, и
> то, не все компиляторы.

Как это - по стандарту? Если в стандарте сказано что эт UB и компилеря варнинингами сыпят? Это как раз пример покладания на стандарты програмером.

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

178. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 23-Апр-24, 14:14 
> Как это - по стандарту? Если в стандарте сказано что эт UB
> и компилеря варнинингами сыпят? Это как раз пример покладания на стандарты
> програмером.

А если не сыплят? Потому что в стандарте про варнинги ничего не сказано?))
Если тебе норма называть стандартом, то что работает не стабильно, то ладно, не буду спорить.


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

181. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 23-Апр-24, 14:48 
> А если не сыплят?

"А если рельсу?!" (c) суровые сибирские мужики vs лесопилка.

> Потому что в стандарте про варнинги ничего не сказано?))

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

> Если тебе норма называть стандартом, то что работает не стабильно, то ладно,
> не буду спорить.

Ну остальные даже и так не смогли - так что даже и сравнить то не с чем. Не, конечно есть ECMA для жаба скрипта. Но там вообще можно приравнять бананы к самосвалам, это нормалек и by design. Что сие означает и будет ли это корректно работать - ну, вы поняли. Но это тоже по стандарту. И дажэе варнинга может не быть, ибо не баг .

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

184. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 23-Апр-24, 15:37 
> "А если рельсу?!" (c) суровые сибирские мужики vs лесопилка.

Ну так это просто еще одна проблема)

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

ИСО стандраты (на который так неистово нафапывают сишники) есть для совсем небольшого кол-ва языков.
Среди которых не только Ada, Fortran и COBOL, но и Pascal с BASIC'ом.
И что-то я не видел такого кол-ва UB и прочего сделаго спустя рукава, в их стандартах.
Так что стандарт стандарту рознь, на жаваскрипте ядро писать не будут (надеюсь)


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

207. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 26-Апр-24, 23:54 
>> "А если рельсу?!" (c) суровые сибирские мужики vs лесопилка.
> Ну так это просто еще одна проблема)

А что, я могу это хрустикам вернуть с gccrs который (пока еще) без боров-чекера. Вопросы полноты реализации - они такие.

> ИСО стандраты (на который так неистово нафапывают сишники) есть для совсем небольшого
> кол-ва языков.

Зато есть таки ну вот реально - кондовые доки на которые можно равняться. И если это

> Среди которых не только Ada, Fortran и COBOL, но и Pascal с BASIC'ом.

Ну так первые три местами даже бывают. Нишевые штуки, но все же. Остальные два - ну, хз. Они просто дурацкие с самого начала были. И никакой стандарт в этом случае не поможет. Кто сказал что 100% стандартов - в ходу?

> И что-то я не видел такого кол-ва UB и прочего сделаго спустя рукава, в их стандартах.

Ну так их стандарты в основном появились сильно позже. Хотя на лично мое мнение я бы поимел вон тех господ без вазелина и заставил задефайнить все и вся. А noncompliant код - был бы явно маркирован более древней редакцией, было бы сразу видно - UNSAFE.

> Так что стандарт стандарту рознь, на жаваскрипте ядро писать не будут (надеюсь)

Да вообще для жыэса есть и довольно небольшие аккуратные движки. Порой даже таки - соответствующие ECMA какойнить.

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

169. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 23-Апр-24, 12:54 
> Не все ж время использовать каменные топоры.

Да вот блин, вскопать грядку большим экскаватором - можно, но дестроя многовато. Куб грунта за раз (меньше не получается, простите) - хренакс, и вообще не поймешь, грядка это или чего. А после пары таких сессий земледелия проще место жительства сменить, чтобы не жить на свалке, и дом как раз куда-то сползать начал.

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

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

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

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

А вот как раз педальность всяких указателей и проч - позволяет очень крутые оптимизации. Которые более продвинутые ЯП не могут себе позволить из-за даваемых гарантий.

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

174. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 23-Апр-24, 13:40 
> Да вот блин, вскопать грядку большим экскаватором - можно, но дестроя многовато.
> Куб грунта за раз (меньше не получается, простите) - хренакс, и вообще не поймешь, грядка это или чего.

Так копай маленьким) Они же тоже существуют.
А еще есть мотоблоки. Тоже оптимизация.

Но пример хороший.
Когда код был размером с грядку то лопаты хватало. Утилитки на 10 LOC, которые можно писать принимая патчи по почте (хорошо хоть не голубиной).
Кто в здравом уме будет 40 соток копать ручками?

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

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

А типа ядро это сейчас не свалка?)

> В C99 и далее частично починили - но увы, не хватило комитета тупарей на полный вариант того что надо было сделать.

Т.е есть проблему решить не смогли.

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

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

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

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

> А вот как раз педальность всяких указателей и проч - позволяет очень
> крутые оптимизации. Которые более продвинутые ЯП не могут себе позволить из-за
> даваемых гарантий.

Это было актуально, когда компы были медленные. И интернета не было)
Ты готов поменять увеличение производительности на 5-10-15% в обмен на потенциальный бекдор?
Сейчас я не готов на такие жертвы.

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

179. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Аноним (-), 23-Апр-24, 14:19 
> Так копай маленьким) Они же тоже существуют.
> А еще есть мотоблоки. Тоже оптимизация.

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

> Кто в здравом уме будет 40 соток копать ручками?

Да легко. Нанимают кучутаджиков и всем пофиг как. Это ж разово.

> А теперь участок стал много гектаров.

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

> Приходит такой васян с лопатой и фигак, разломал что-то важное. И даже не заметил.

То ли дело экскаваторщик. Копнул, взорвалось 2 бомбы, е...шит высоковольтный кабель, фигачит фонтан, а перепуганые жители спешно сдристывают из локации кто во что горазд, если было куда, чтобы не гадать прибьет их напряжением в паре с водичкой от фонтана - или таки осколками бомб?

> А потом через 10 лет, кто-то обнаружи утечку фекалий прямо юзеру запазуху.

По сравнению с вон тем это, возможно, не такая уж большая проблема была...

> Т.е есть проблему решить не смогли.

Т.е. решили половинчато. Но да, в целом - незачет.

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

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

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

Ну как бы есть штуки типа C4. Это компилер если что, а не... - C in 4 functions :). А нечто типа tcc - даже и довольно полный C99 так то, с вполне обозримой кодовой базой. Много ли иных яп вообще таким похвастать могут? У сишки реально простое языковое core. Остальным на ЭТО талантов явно не хватило. Увы и ах. Какой-нибудь хруст например костылили, костылят и будут костылить.

> Это было актуально, когда компы были медленные. И интернета не было)

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

> Ты готов поменять увеличение производительности на 5-10-15% в обмен на потенциальный бекдор?

В ядре это и в разы может оказаться. Вооон там игогошики проверяли с драйвером FAT32 на го. Познали горя по полной програме. Пока занимались всем этим миндфаком - наступил кризис, гугл вообще проект задвинул. Ну что, накорябали концЭптуальный драйвер, джуны?! :)

> Сейчас я не готов на такие жертвы.

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

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

91. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +/–
Сообщение от Fracta1L (ok), 22-Апр-24, 13:46 
При программировании на сишке нужно выполнять уйму ручной работы.

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

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

134. "Lunatik - инструментарий для создания в ядре Linux обработчи..."  +2 +/–
Сообщение от Аноним (-), 22-Апр-24, 18:14 
> А уйма ручной работы как раз оставляет меньше времени на думанье.

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

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

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

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




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

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