Профиль: Аноним (вход | регистрация) неRU opennet.me  
The OpenNET Project / Index page

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



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

"Представлен crustc - компилятор rustc, переведённый на язык Си"  +/
Сообщение от opennews (??), 03-Июл-26, 10:36 
Опубликован crustc, компилятор для языка Rust, созданный путём трансляции кода штатного компилятора rustc 1.98.0-nightly на язык Си. На выходе получилось 46 млн строк кода на Си, которые можно собрать при помощи GCC и утилиты make. Собранный таким способом компилятор успешно проходит тесты компиляции Rust-кода, такого как стандартные rust-библиотеки...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65834

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

Оглавление

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

1. Сообщение от Аноним (1), 03-Июл-26, 10:36   +50 +/
Вот это поворот!))
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #120, #121

3. Сообщение от Аноним (3), 03-Июл-26, 10:38   +14 +/
Ну все, скажите парням из OpenBSD что проблему доверия к компилятору rust теперь можно решитт; дело за малым, осталось только провести ревью 46 миллионов строк Си кода;)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #97, #163

4. Сообщение от Аноним (131), 03-Июл-26, 10:43   –2 +/
Это изначально не было проблемой, поскольку изначально rust был написан на ocaml.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5

5. Сообщение от Аноним (3), 03-Июл-26, 10:48   +4 +/
Да какая разница на чем он был изначально написан! Проблема доверия от этого никуда не исчезает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #8

6. Сообщение от Аноним (6), 03-Июл-26, 10:54   +11 +/
Еще бы Firefox вот так в Си оттрансливароть, чтоб вообще без раста собирался и без всяких llvm.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #158

7. Сообщение от Аноним (14), 03-Июл-26, 11:00   +6 +/
Т.е. теперь можно будет собрать раст не собирая раст?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #135

8. Сообщение от Аноним (131), 03-Июл-26, 11:00   –3 +/
Какая проблема доверия? Берите исходный код и читайте, или у вас лапки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #12, #14, #15, #122

10. Сообщение от Андрей (??), 03-Июл-26, 11:06   +/
"46 млн строк кода на Си"...
И нафига?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18

12. Сообщение от Аноним (3), 03-Июл-26, 11:10   +2 +/
Удачи вам в ревью 46 миллионов кода на Си;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #42, #107

14. Сообщение от Аноним (14), 03-Июл-26, 11:11   +3 +/
Доверие к разрабам, которые сопровождают раст или ты предлагаешь мониторить их каждый комит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #43

15. Сообщение от Аноним (3), 03-Июл-26, 11:12   –1 +/
Похоже вы не совсем понимаете в чем суть Trusting Trust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #34

18. Сообщение от Аноним (3), 03-Июл-26, 11:23   +/
Важен сам факт разрыва цепочки через Си-код и условный GCC, что позволит решить проблему Trusting Trust "математеческим бутсраппигом". Однако для "человеческого бутстраппинга", невозможность ревью означает, что проблема доверия остается нерешенной! Это одна из причин по которой, например OpenBSD не будут этим пользоваться. А вот для других проектов, этого будет вполне достаточно!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #26, #41, #165

20. Сообщение от aname (ok), 03-Июл-26, 11:28   +4 +/
> позволяющего транслировать проекты с языке Rust на язык Си

Это должно было появиться, рано или поздно

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

22. Сообщение от Аноним (22), 03-Июл-26, 11:38   +2 +/
Интересно было бы сравнить время компиляции компилятора на rust и на с.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #74, #89, #145

24. Сообщение от Аноним (24), 03-Июл-26, 11:56   +/
Ну теперь есть второй компилятор. Уже хорошо. Снижает риск бэкдоров в компиляторе.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

25. Сообщение от xsignal (ok), 03-Июл-26, 12:01   +/
Никогда ещё Штирлиц не был так близок к провалу!))
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от Аноним (26), 03-Июл-26, 12:01   –1 +/
> Это одна из причин по которой, например OpenBSD не будут этим пользоваться. А вот для других проектов, этого будет вполне достаточно!

Эээ? а опенБздяшники они какие-то особенные?
Такоей же сишный овнокод с CVE/RCE.

Учитывая что оно нигде не нужно, то можно судить о её качестве.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #108

29. Сообщение от Аноним (113), 03-Июл-26, 12:06   +9 +/
Ясно, теперь rustc не нужен. Очередное доказательство, что Си из-за своего простого синтаксиса и остальных удобств переживет всех и вся.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45

30. Сообщение от Аноним (-), 03-Июл-26, 12:11   +3 +/
Уж простите зануду но TrustingTrust для раста давно решен с помощью mrustc, по крайней мере для x86_64.

Эти бы усилия да на решению той же проблемы для  FreePascal. Который ничем кроме себя и античного делфи не собрать.

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

31. Сообщение от Аноним (34), 03-Июл-26, 12:11    Скрыто ботом-модератором–1 +/
Ответить | Правка | Наверх | Cообщить модератору

34. Сообщение от Аноним (34), 03-Июл-26, 12:19   +/
Trusting Trust - Доверяющий Доверяю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

35. Сообщение от Аноним (35), 03-Июл-26, 12:20   –1 +/
Нужен не компилятор, а стандарт. Тогда проблема доверия переместится с языка на реализацию. И ту уже все будет просто -- вы либо доверяете конторе, выпустившей реализацию компилятора или не доверяете.
Если не будет стандарта, то доверие к языку появится через лет десять. после того, как он заморозится. В смысле, сорвременный компилятор будет генерировать бит в бит такой же код для эталонной программы, как и десятилетний.
Лично для меня сигналом доверия будет тот факт, что rust-компилятор выпустит IBM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #46, #47

36. Сообщение от Аноним (35), 03-Июл-26, 12:24   +1 +/
Компилятор для языка L, претендующего на системный, должен собираться компилятором для языка L без привлечения каких-либо утилит и библиотек третьей стороны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #60, #132

37. Сообщение от Аноним (37), 03-Июл-26, 12:25   –2 +/
rustc -> crustc -> c..c -> cc
Ответить | Правка | Наверх | Cообщить модератору

38. Сообщение от Alladin (?), 03-Июл-26, 12:29   –2 +/
раст в си конечно возможно, а вы попробвйте наоборот
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

39. Сообщение от xsignal (ok), 03-Июл-26, 12:35   +/
Теперь всё, что понаписали на Расте нужно сконвертировать в Си! =)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40, #70

40. Сообщение от Аноним (37), 03-Июл-26, 12:41   +/
переписать на Си
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

41. Сообщение от Аноним (131), 03-Июл-26, 12:43   +/
>Это одна из причин по которой, например OpenBSD не будут этим пользоваться.

Объясните, как вы собираетесь решать аналогичную проблему для clang/llvm и gcc. Или опять стрелочка не поворачивается?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #81

42. Сообщение от Аноним (131), 03-Июл-26, 12:44   +1 +/
У вас было более десяти лет, чтобы прочитать код компилятора. На что вы жалуетесь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #48

43. Сообщение от Аноним (131), 03-Июл-26, 12:45   +/
Объясните, как вы решаете аналогичную задачу для clang/llvm и gcc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #85

45. Сообщение от Facemakeremail (?), 03-Июл-26, 12:48   +2 +/
Удобств.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

46. Сообщение от Аноним (131), 03-Июл-26, 12:48   +/
>Нужен не компилятор, а стандарт.

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

Такого не то что не будет для rust, такого нет даже для си.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #59, #66, #100

47. Сообщение от Аноним (26), 03-Июл-26, 13:04   +2 +/
> Нужен не компилятор, а стандарт.

Отлично!
У вас есть стандарт ISO/IEC 9899.
И ни одного опенсорскного компилятора который реализовал бы его полностью.
Здорово правда!? (с)

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

А еще в стандарте можно поменять поведение напр добавить UB.
Как и поступили в С23.

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

Хахаха, отличный подход.

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

В мире куча ЯП без стандартов и с доверием проблем нет.
У раста тоже нет - так как топовые компании используют его в проде.

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

А условный GCC так усмеет? Они же поведение иногда ломат даже в не мажорных версиях

> Лично для меня сигналом доверия будет тот факт, что rust-компилятор выпустит IBM.

Но зачем? Им проще посадить своего чувака в раст-фаундешн и пусть работает.

Кстати недавно в ядро добавили поддержку раст для s390
https://lore.kernel.org/rust-for-linux/20260512105920.242629.../

IBM предлагает "IBM Open SDK for Rust on AIX"
www.ibm.com/products/open-sdk-for-rust-aix

и на сайте есть туториалы Beginner's guide to Rust

Кажется IBM больше доверяет языку без стандарта, чем аноним с форума))


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

48. Сообщение от Аноним (48), 03-Июл-26, 13:08   +/
какие 10 лет, если репозиторий crustc появился 5 дней назад? Или по вашему результат ревью rustc автоматически переносится на crustc?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #62

49. Сообщение от Archer73 (ok), 03-Июл-26, 13:13   +4 +/
А разве "наоборот", это не любимое развлечение программистов на Rust. Мне кажется их больше всего критикуют за переписывание того, что и так работает, хотя есть много гораздо более нужных направлений
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #56, #63, #159

50. Сообщение от Ананоним (?), 03-Июл-26, 13:25   +/
Это тоже компилит так что нужно 32 Гигабайта ОЗУ?
Ответить | Правка | Наверх | Cообщить модератору

55. Сообщение от Аноним (56), 03-Июл-26, 13:34   –1 +/
Разве у llvm не было C бэкенда?
Ответить | Правка | Наверх | Cообщить модератору

56. Сообщение от Аноним (56), 03-Июл-26, 13:35   –5 +/
> что и так работает

* не работает. Код на C почти никогда не работает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #75

57. Сообщение от Аноним (60), 03-Июл-26, 13:38   +2 +/
C 100.0%
Я правильно понимаю, что crustc не требует LLVM ? Если так, то он определённо удобней, чем cilly, который бекенд к rustc.
Ответить | Правка | Наверх | Cообщить модератору

59. Сообщение от Аноним (59), 03-Июл-26, 13:43   +/
> Покажите мне язык со стандартом, который имеет несколько реализаций, которые можно прозрачно заменить, без появления кучи багов, просадки производительности и несовместимых реализаций.

POSIX shell

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #64

60. Сообщение от Аноним (60), 03-Июл-26, 13:51   –1 +/
А для раскрутки языка L, его компилятор первый раз должен собираться компилятором языка L, написанным на языке C. Чтобы никаких блобов в архиве исходников языка L не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #65

62. Сообщение от Аноним (131), 03-Июл-26, 14:00   –1 +/
>какие 10 лет, если репозиторий crustc появился 5 дней назад?

Во-первых не 10 лет, а более 10 лет, во-вторых в первом сообщении вопрос доверия поднимался к rust, а не к rustc.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #104

63. Сообщение от Аноним (115), 03-Июл-26, 14:05   +/
> Мне кажется их больше всего критикуют за переписывание того, что и так работает,

Ты слегка ошибся, правильно писать: ʼи так "сойдет" работаетʼ.
В ядре за неудачный месяц нашли 1000+ CVE.
В зловонной куче X11 расколупывают дырки которым по 30+ лет.
Куча библиотек (включая криптографию) допускают зловредные манипуляции.

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

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #72

64. Сообщение от Аноним (131), 03-Июл-26, 14:16   +/
Какой замечательный пример. Во-первых, под POSIX shell мало кто не пишет. Во-вторых, кроме самого shell-а, для работоспособности скрипта критически важно иметь совместимые версии утилит, поскольку даже у GNU Coreutils и у BusyBox различаются ключи. В-третьих, при любой правке скрипта придётся тщательно следить за изменениями и окружением, в котором запускается скрипт, так как если в скрипт попадёт, например, башизм, то никакой ошибки это не вызовет. Никакой прозрачностью тут и не пахнет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #67, #154

65. Сообщение от Аноним (131), 03-Июл-26, 14:18   –2 +/
>его компилятор первый раз должен собираться компилятором языка L, написанным на языке C

Нет, не должен. Си - это ужасный язык, в том числе и для написания компилятора.
>Чтобы никаких блобов в архиве исходников языка L не было.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #77

66. Сообщение от Аноним (-), 03-Июл-26, 14:19   +/
> Покажите мне язык со стандартом, который имеет несколько реализаций, которые можно прозрачно заменить, без появления кучи багов, просадки производительности и несовместимых реализаций.

Ada

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #69, #73

67. Сообщение от Аноним (131), 03-Июл-26, 14:19   +1 +/
>мало кто не пишет

Мало кто пишет. В основном, пишут под bash или какую-то другую, несовместимую реализацию.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #155

68. Сообщение от Соль земли2 (?), 03-Июл-26, 14:21   –2 +/
Какая связь между окружением для сборки и запуска программы? В Docker для этого даже разные контейнеры используют.
Ответить | Правка | Наверх | Cообщить модератору

69. Сообщение от Аноним (131), 03-Июл-26, 14:21   +/
Мне лень проверять ваше утверждение, но какие проекты больше чем hello world можно им собрать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #142

70. Сообщение от Соль земли2 (?), 03-Июл-26, 14:24   +/
Rust придумали, чтобы не писать на Си...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #82

72. Сообщение от Ivan_83 (ok), 03-Июл-26, 14:28   +/
И только вам настолько нечем занятся по жизни что вас это волнует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #76

73. Сообщение от Аноним (73), 03-Июл-26, 14:30   +/
> Ada

Хороший пример.
Надо еще упомянуть, что у них есть есть "сертификация" компилятора.
Для того чтобы называться "компилятор языка Ada" нужно пройти 1000+ тестов.
Один завалил? Свободен.

А теперь сравните это с "стандартом" СИ, на который так наяривают местные.
Опенсорсных компиляторов которые реализовывали весь стандарт - нет.
В каждом лепят свои велосипеды - в итоге выхлоп шланга отличается от ЖЦЦ, а тот отличается от поделия мелкомягких.
"Переносимость" (на которую тоже наяривают местные) можешь догадаться какая)

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #98, #113, #170

74. Сообщение от Ivan_83 (ok), 03-Июл-26, 14:31   –1 +/
Вот мне тоже интересно.
Если оно как VALA - типа синтаксис ок - транслируем, без этих душнильных проверок всего и вся - то скорее всего будет быстрее собиратся.

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

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

75. Сообщение от Ivan_83 (ok), 03-Июл-26, 14:31   +4 +/
Ну теперь то понятно почему растовики не любят С - оно у них не получается :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

76. Сообщение от Аноним (76), 03-Июл-26, 14:32   +1 +/
> И только вам настолько нечем занятся по жизни что вас это волнует.

Ну тебе точно хватило "нечем заняться" чтобы оставить коммент)

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #78

77. Сообщение от Аноним (115), 03-Июл-26, 14:37   –2 +/
> Нет, не должен. Си - это ужасный язык, в том числе и для написания компилятора.

А компиляторов на СИшке почти не осталось.
Даже великий и ужасный GCC стали писать на С++.
Почему? Потому что на СИшном убожестве нельзя сделать крутой оптимизирующий компилятор.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #99

78. Сообщение от Ivan_83 (ok), 03-Июл-26, 14:40   +/
Так вы не видели как было раньше, и какой прогресс произошёл за последние лет 15.

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

Чтобы было понятно.
1. В начале софт писали и тестили по ходу написания ручками. (pre 2000)
2. Потом начали принимать багрепорты от пользователей. (2000+)
3. Добавили автотесты. (2010+)
3.5. Где то тут появился гитхуб и платформы совместной разработки, а так же всякие автоматические отправки отчётов о крашах. (2010+)
4. Стали юзать фазеры (2020+)
5. Стали юзать ИИ. (2024+)

И надо понимать что от начали до результата где то могло пройти 5-10 лет, где то хватило 1-2 года.
Мне как юзеру опенсорца и не только вот прям сильно видно прогресс за последние 10 лет, притом оно наладилось ещё до прихода ИИ - всмысле перестало падать во время работы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #79, #93

79. Сообщение от Ivan_83 (ok), 03-Июл-26, 14:45   +/
Ну и да, этот ваш раст появился в 2015 примерно, до фазеров и ИИ.

Ещё я забыл написать про развитие статических анализаторов, того как компиляторы анализируют и то что наконец то этим всем начали пользоватся.

Поэтому раст - это про альтернативное решение проблем, а не единственно верный путь и пр.

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

81. Сообщение от Аноним (3), 03-Июл-26, 15:08   +/
В том и суть, - это практически неподъемная да и нецелесообразна задача, (особенно это касается оптимизатора!).

Парни пытались решить этот вопрос очень давно (делали ставку на PCC, но увы ничего не вышло). У них и так хватает работы (к слову, команда у них небольшая), поэтому они выбрали прагматичный подход:

Смириться с Clang как с неизбежным злом! Они просто пропатчили его с помощью unveil и pledge. Парни красавцы!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #84, #88, #137

82. Сообщение от Аноним (60), 03-Июл-26, 15:08   +3 +/
Чтобы переписывать с Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

84. Сообщение от Аноним (84), 03-Июл-26, 15:23   +/
> Парни пытались решить этот вопрос очень давно (делали ставку на PCC, но увы ничего не вышло). У них и так хватает работы (к слову, команда у них небольшая), поэтому они выбрали прагматичный подход:

Какое классное оправдание неудачников)

> Смириться с Clang как с неизбежным злом!

Ну т.е просто поменяли свои убеждения.

> Парни красавцы!

Конечно красавцы, так легко стрелочку поворачивать.

Правда OpenBSD от этого нужнее не стала.


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

85. Сообщение от Аноним (3), 03-Июл-26, 15:28   +1 +/
По поводу clang, ответил в другом комментарии. Что касается gcc, почитайте про stage0-posix, Gnu Mes, M2-Planet, Gnu Mes.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #87

87. Сообщение от Аноним (131), 03-Июл-26, 15:34   –2 +/
>Что касается gcc, почитайте про stage0-posix, Gnu Mes, M2-Planet, Gnu Mes.

Вы либо некомпетентны, либо предвзяты. Выше сказано:
>или ты предлагаешь мониторить их каждый комит?

Каким образом вам поможет сборка из исходников, если в исходниках уже будет проблема?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #91

88. Сообщение от Аноним (131), 03-Июл-26, 15:36   +1 +/
>В том и суть, - это практически неподъемная да и нецелесообразна задача

Тогда зачем вы поднимаете этот вопрос?
>Парни пытались решить этот вопрос очень давно

Какие парни? Как минимум в портах openbsd rust присутствует.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #94

89. Сообщение от Аноним (89), 03-Июл-26, 15:40   +2 +/
Вообще без разницы. Лучше пару суток GCC молотит, чем собирать llvm, rust и вот это всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #90

90. Сообщение от Ivan_83 (ok), 03-Июл-26, 15:56   –1 +/
llvm нынче нужен для mesa и ещё всякого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #92

91. Сообщение от Аноним (3), 03-Июл-26, 15:58   –1 +/
Идея проста:

1. Исходник, например hex0_x86.hex0 мал — значит, человек может полностью прочитать его глазами и гарантировать, что в самом тексте программы нет никаких скрытых закладок. Там просто негде их спрятать.

2. Результат мал — значит, получившиеся байты тоже можно проверить глазами (или простейшим побайтовым сравнением) и убедиться, что инструмент сборки ничего не дорисовал от себя.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #95

92. Сообщение от Аноним (92), 03-Июл-26, 16:05   +1 +/
llvm уже не является обязательным для mesa — оная давно перешла на NIR.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

93. Сообщение от Аноним (131), 03-Июл-26, 16:06   +/
>Так вы не видели как было раньше, и какой прогресс произошёл за последние лет 15.

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

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

И много программ со свободным кодом отправляют данные отчёты?
>всмысле перестало падать во время работы

Абсурдный критерий. Лучше упасть по исключению, чем допустить эксплуатацию уязвимости.
>Ещё я забыл написать про развитие статических анализаторов, того как компиляторы анализируют и то что наконец то этим всем начали пользоватся.

Которые не работают. Ещё раз приведу вам пример:
$ cat b.h
struct A {
        int** p;
};

void set_null(struct A*, int**);
int print(struct A*);
$ cat b.c
#include "b.h"

void set_null(struct A* a, int** p)
{
        a->p = p;
}

int print(struct A* a)
{
        int** x = a->p;
        return **x;
}
$ cat a.c
#include <stdio.h>
#include "b.h"

int main()
{
    int y = 7, x = 8;
    int* p_y = &y;
    int* arr[] = {&y, NULL, &x};
    struct A a = {.p = &p_y };
    printf("%d\n", print(&a));
    set_null(&a, arr);
    int num, ret;
    printf("Press 1 and press Enter\n");
    ret = scanf("%d", &num);
    //num = 1;
    arr[0] = arr[num];
    printf("%d", print(&a));
    return 0;
}
$ gcc -flto -fanalyzer b.c -c -o b.o && gcc -flto -fanalyzer a.c -c -o a.o && gcc -fanalyzer a.o b.o -o a && ./a
7
Press 1 and press Enter
1
Segmentation fault         (образ памяти сброшен на диск) ./a
$

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #116

94. Сообщение от Аноним (3), 03-Июл-26, 16:08   +/
Господи, да мой самый первый комментарий по этой теме был полнейшим рофлом, Карл!) Из которого должно быть понятно что имеется ввиду, но похоже не вам!;) Далее человек спросил вопрос, где это может быть полезно, и я ему ответил. А уже далее появились вы, и именно вы подняли данный вопрос касательно gcc, llvm! По-моему я ответил и на ваш вопрос. В общем, не будьте таким душным:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #96, #171

95. Сообщение от Аноним (131), 03-Июл-26, 16:11   +/
Нет. Исходник условного mes вы можете прочитать быстро, исходник gcc 16.0, вы не просто не прочтёте, вы его ещё и не соберёте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #101

96. Сообщение от Аноним (131), 03-Июл-26, 16:12   +/
Вы первый день в интернете? Может нужно предполагать, что когда вы пишите очередную глупость, вам всё равно потом придётся оправдываться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #102

97. Сообщение от Аноним (97), 03-Июл-26, 16:16   +/
А сколько строк у оригинала?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

98. Сообщение от Аноним (131), 03-Июл-26, 16:18   +/
>Хороший пример.

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

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

99. Сообщение от Аноним (60), 03-Июл-26, 16:22   +/
В случае, когда компилятор только для раскрутки, то можно вообще без каких-либо оптимизций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #133

100. Сообщение от Аноним (137), 03-Июл-26, 16:43   +/
Common Lisp.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

101. Сообщение от Аноним (3), 03-Июл-26, 16:58   +/
Смысл в том, что вам первым делом нужен стартовый-доверенный бинарник  Именно ради этого все эти танцы с бубном!

А вот дальше, чтобы убедиться что в этой цепочке (на каком-то этапе, условно ваш gcc16) не произойдет подстава, используются следующие методы:

1. Воспроизводимая сборка (Reproducible Builds)
2. Метод двойной компиляции (Diverse Double-Compiling / DDC)
3. И наконец, вами упомянутый, но как видите, не единственный способ: Аудит и верификация исходников.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #105

102. Сообщение от Аноним (3), 03-Июл-26, 17:09   +/
Вы получили ответ на свой вопрос, так ещё и чем-то недовольны:) В общем, идите и разбирайтесь в данном вопросе самостоятельно, а "глупый я" удаляюсь:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

104. Сообщение от Аноним (-), 03-Июл-26, 17:20   –1 +/
перечитай сообщение, там про доверие к компилятору rust, а не к rust.
И ревью 46 миллионов строк это не про rustc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

105. Сообщение от Аноним (131), 03-Июл-26, 17:37   +/
Вы можете точно так же с нуля собрать rust, поскольку первая версия компилятора была написан на Ocaml.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #114

106. Сообщение от Аноним (106), 03-Июл-26, 18:07   +5 +/
Теперь нужно переписать эти 45 млн. строк обратно на Rust, чтобы было "безопасно".
Ответить | Правка | Наверх | Cообщить модератору

107. Сообщение от morphe (?), 03-Июл-26, 18:11   +1 +/
Это выхлоп компилятора, промежуточный артефакт, зачем его ревьюить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

108. Сообщение от Анонимemail (108), 03-Июл-26, 18:16   +2 +/
CVE/RCE в коде на пидо расте побольше. Или по твоему существует только уязвимости с памятью
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #110

110. Сообщение от Аноним (110), 03-Июл-26, 18:24   –1 +/
> CVE/RCE в коде на пидо расте побольше.

Ты выcpaл свой коммент, но забыл приложить пруфы.
Я понимаю, что дырявые не любят отвечать за свои слова, но попробуй в этот раз преодолеть свои СИшные наклонности.

> Или по твоему существует только уязвимости с памятью

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

Но мы можем посмотреть
cvedetails.com/vendor/33/Linux.html
и заметить что Memory Corruption как минимум на порядок обгоняет остальные.

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

113. Сообщение от Аноним (113), 03-Июл-26, 19:29   –1 +/
>Опенсорсных компиляторов которые реализовывали весь стандарт - нет.

Есть - GCC
https://en.cppreference.com/c/compiler_support

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #115

114. Сообщение от Аноним (3), 03-Июл-26, 19:56   +/
Как вы думаете, почему в конечном итоге появился такой проект как mrustc? Да потому, что в какой-то момент, те люди кто этим реально занимались, поняли что путь через OCaml — это тупик! Из-за чего же? -  и ответ, то с чего начинался ваш вопрос - это мать его LLVM!!!!!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #118

115. Сообщение от Аноним (115), 03-Июл-26, 19:59   +/
>>Опенсорсных компиляторов которые реализовывали весь стандарт - нет.
> Есть - GCC
> https://en.cppreference.com/c/compiler_support

Слово "partial" тебе что-то говорит?
Частично поддерживает? На пол шишечки?

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

116. Сообщение от Ivan_83 (ok), 03-Июл-26, 20:05   +/
> Первый же эксплоит эти ошибки отлично эксплуатируют.

Так вы зажрались :)
Раньше достаточно было мышкой пошевелить чтобы прога упала :)

А экплоит ещё поди подсунь...


> И много программ со свободным кодом отправляют данные отчёты?

Без понятия.


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

Так и говорю: зажрались вы!
Экплоит им мешает видители.
А не хочите падать на обычных действиях!?
Думаете почему в MS Word и многих других прогах есть автосохранение какждые 5 минут?
А потому что оно падало часто: сидишь, редактируешь текст а оно бах и на ровном месте скрашилось.
Вот прямо так, без всяких эксплоитов.


> Которые не работают. Ещё раз приведу вам пример

Так и что?
С не знает можете вы прочитать память по адресу NULL или нет.
Это валидный код, который даже не везде будет падать и не всегда.
Никто не запрещает смапить память на 0x000000000 адрес для процесса и хранить там валидные данные.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #117, #123, #172

117. Сообщение от Ivan_83 (ok), 03-Июл-26, 20:19   +/
security.bsd.map_at_zero: Permit processes to map an object at virtual address 0.

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

И собственно NULL - это часто (void*)0, не более чем соглашение по API что если вернули такое значение то типа сфейлились.
И то что оно (void*)0 - тоже не везде.

Короче мир сильно сложнее и разнообразнее чем вам с вашим языком кажется.

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

118. Сообщение от Аноним (131), 03-Июл-26, 20:27   –1 +/
А LLVM тут причём? Он вообще на крестах написан, собирай - не хочу. Вы можете изложить свою точку зрения целиком, а не разорвано, в куче сообщений?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #126

119. Сообщение от Аноним Анонимович Анонимов (?), 03-Июл-26, 20:29   +1 +/
> На выходе получилось 46 млн строк кода на Си

Больше, чем ядро Linux (43 млн строчек кода https://www.phoronix.com/news/Linux-7.2-43-Million-Lines)

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

120. Сообщение от Аноним (120), 03-Июл-26, 20:48   +1 +/
> ... находящегося в разработке компилятора cilly, позволяющего транслировать проекты с языка Rust на язык Си

Ну вот, об этом уже предупреждали, что к этому всё скатится.

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

121. Сообщение от Я (??), 03-Июл-26, 21:19   +/
Объясните безграмотному мне, во что здесь компилируется rust? C, вроде, в инструкции для процессора, а это во что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #129

122. Сообщение от Аноним (122), 03-Июл-26, 21:28   +/
Параноя насчет доверенного компилятора основана на том, что левый компилятор может от себя   вставлять в результат компиляции бэкдоры, которых не было в исходном коде компилируемой программы. Например, может искать и изменять функции проверки паролей, RND-генераторов  и т.п.
Решается путем написания примитивнейшего с-компилятора, бинарь которого можно дизассемблировать и проверить, что там нет ничего лишнего. Потом с помощью этого убожества компилируется более мощный с-компилятор, бинарь которого уже гарантировано соответсвует исходному коду. Потом компилится еще более мощный и т.д. До актуальной версии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #124, #125

123. Сообщение от Аноним (131), 03-Июл-26, 21:39   +/
>Раньше достаточно было мышкой пошевелить чтобы прога упала :)

Раньше - это когда? Нет никакого раньше. Кто-то уже в 2005 уже писал SharpDevelop на c#, а это - 21 год назад. Если отмотать время ещё раньше, то можно вспомнить про VisualBasic. В восьмидесятые появился StandardML. И наоборот, какие-то программы падают до сих пор. Тот же GNOME Wayland падал под конец десятых, хотя казалось бы.
>С не знает можете вы прочитать память по адресу NULL или нет.

Да? А зачем тогда нужны все эти флаги?
>Это валидный код, который даже не везде будет падать и не всегда.

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

При чём здесь микроконтроллеры? Каждый раз, когда заходит речь о настольных/серверных приложениях, вы постоянно пытаетесь съехать куда-то далеко.
>И то что оно (void*)0 - тоже не везде.

И? Какое из моих слов это отменяет?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #128

124. Сообщение от Аноним (122), 03-Июл-26, 21:40   +/
к тому-же, если левый компилятор определит, что компилируемая программа является компилятором  то он может вставить в бинарь весь свой левый функционал по вставке бэкдоров и модификации компиляторов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #140

125. Сообщение от Аноним (131), 03-Июл-26, 21:41   –1 +/
Опять двадцать пять. Да сколько можно? Берите, откатывайтесь к самым первым коммитам, и там у вас будет замечательнейшая возможность собрать компилятор без блобов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #136

126. Сообщение от Аноним (3), 03-Июл-26, 21:52   +/
Ясно, понятно, вы вообще не разбираетесь в теме, поэтому что-то продолжать объяснять бессмысленно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #130

127. Сообщение от Мемоним (?), 03-Июл-26, 22:04   +1 +/
Вот тоже кстати удивило. Сколько там на Русте в исходных исходниках?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #173

128. Сообщение от Ivan_83 (ok), 03-Июл-26, 22:06   +/
> Раньше - это когда? Нет никакого раньше. Кто-то уже в 2005 уже писал SharpDevelop на c#, а это - 21 год назад. Если отмотать время ещё раньше, то можно вспомнить про VisualBasic.

Раньше это года до 2010-2020.

И вижалбейсик и шарп фигня - оба были тормозными и годились только для небольших простых приложений.
Нет, на них конечно можно было и всякое разное понаписать, но в какой то момент ты приходил к пониманию что проще бросить и написать на С или чём то ещё.
Потому что на вижалбейсике сложные гуи делать было намного сложнее чем на С, а производительность была оч низкая, и приходилось оффлоадить на С код всякие ресурсоёмкие вычисления. А по меркам 90-начала 2000х это почти все вычисления.
Шарп появился уже позднее, это была отрыжка мс и попытка с помощью пеара сделать язык универсальным.


> Нет, это заведомо неверный код.

Я вам повторяю ещё раз: запись/чтение по адресу 0x000000 - валидная операция с точки зрения языка.
Успех или не успех этой операции целиком на совести программиста и железа.


> При чём здесь микроконтроллеры? Каждый раз, когда заходит речь о настольных/серверных приложениях, вы постоянно пытаетесь съехать куда-то далеко.

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


> Какое из моих слов это отменяет?

Оно отменяет ваш пример, которым вы пытались показать что встроенная диагностика языка С не отлавливает всего.
На что я вам и возразил: переменную вы заинитили в NULL, дальше это не проблема языка, это ВАША проблема чтобы память была доступна для чтения/записи.

Для адепта "системного" языка стыдно не понимать таких базовых вещей.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #134

129. Сообщение от Аноним (129), 03-Июл-26, 22:43   +1 +/
Новость состоит в том, что все доверяют компилятору си, потому что вы знаете, во что превратится ваша программа. В практически любых других компиляторах это не так, и не потому что языки высокоуровневые, а потому что компиляторы написаны на самих себе, и туда можно заложить код так, что вы не узнаете, как работает конечный компилятор (даже если его код открыт). Теперь, когда люди смогли переписать компилятор раста на си (пускай и в нечитабельный код), становится ясно, что в предыдущих версиях компилятора раста не заложено непредвиденное поведение (условно, потому что, конечно, люди могли буквально написать в конечном компиляторе что-то ужасное, но вы теперь точно сможете это обнаружить)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #131, #143, #157

130. Сообщение от Аноним (131), 03-Июл-26, 23:02   +/
Если бы вы разбирались, то смогли бы написать нечто большее, чем постоянное перепрыгивание с темы на тему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

131. Сообщение от Аноним (131), 03-Июл-26, 23:04   –1 +/
>а потому что компиляторы написаны на самих себе

Осильте наконец-то раскрутку.

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

132. Сообщение от Аноним (-), 03-Июл-26, 23:11   –1 +/
тот же аноним если что)

Уж если что сужествует проект live-bootstrap.

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

Вот пока не пробовал, но что-то мне подсказывает что gcc-10 который он выдает умеет собрать clang которого хватит для mrustc. и так же сможет собрать gcc который ему требуется для компиляции.

Как имея компилятор раст который 2 компиляторами собирается собрать доверенный компилятор боле свежей версии - очевидно...

Лучше займитесь FPC и ada для которых такое не возможно.

Для ada есть разве что компилятор дающий код под sparc при использовании трансляции в С.

Куда более актуальная проблема.

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

133. Сообщение от Аноним (-), 03-Июл-26, 23:15   +/
Вот есть еще люди которые понимают как это работает.

Если есть то что может собрать из исходника и оно работает - TrustingTrust идет лесом.

Поскольку условно доверенный\Проверенный компилятор собирает проверенный исходник.

ТОЧКА. Если доверия нет к чему либо из этого - проблема не в бутстрапе.

Не надо заставлять tcc собирать под свой конкретный проц - дождись пока бутстрап дойдет до рабочего gcc собранного по цепочке.

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

134. Сообщение от Аноним (131), 03-Июл-26, 23:19   +/
>И вижалбейсик и шарп фигня - оба были тормозными и годились только для небольших простых приложений.

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

Это никогда не было проще. Возьмём к примеру создание IDE. И тут, что удивительно, почему-то jvm. И не важно что это - NetBeans, Eclipse или Idea. Emacs можно вспомнить, который почему-то на Elisp-е. Опять не си.
>Потому что на вижалбейсике сложные гуи делать было намного сложнее чем на С

Гнусная ложь. В то время, как у визуал бейсика можно было создать окно, перетаскивая элементы мышкой, в c у вас не то что визуального редактора не было, у вас ещё и необходимость следить за утечками памяти и ручной обработки сигналов.
>Я вам повторяю ещё раз: запись/чтение по адресу 0x000000 - валидная операция с точки зрения языка.

Вы нагло врёте, даже не стесняясь. Разыменновывание nullptr - UB. При его наличии, компилятор может произвольным образом переписать код.
>С - универсальный язык

Универсальность абсолютно никак не отменяет наличие UB.
>На что я вам и возразил: переменную вы заинитили в NULL, дальше это не проблема языка, это ВАША проблема чтобы память была доступна для чтения/записи.

Вы для начала объясните, почему если немного переписать код, расскоментировав закоментированную строку, то компилятор ВНЕЗАПНО просыпается и видит проблему?
>Для адепта "системного" языка стыдно не понимать таких базовых вещей.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #139, #149

135. Сообщение от Аноним (135), 03-Июл-26, 23:27    Скрыто ботом-модератором+1 +/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

136. Сообщение от Аноним (122), 03-Июл-26, 23:33   +/
вы, видимо, смешиваете две совершенно разные вещи: доверие разработчикам и доверие компилятору, про которое был первый пост.
Доверие компилятору в первом посте - это вообще не про исходный код компилятора, и никаким code review  это в принципе не может быть решено, даже если бы в компиляторе  было всего десяток строк кода, потому что недоверенный компилятор сам может вставить в результирующий бинарник ТО, ЧЕГО НЕТ В ИСХОДНОМ КОДЕ.
Для, примерно, 100% пользователей компиляторов эта проблема является чисто теоретической и не актуальной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

137. Сообщение от Аноним (137), 03-Июл-26, 23:53   +/
> Они просто пропатчили его с помощью unveil и pledge.

Ты сейчас реально предлагаешь доверять программисту не напортачить с unveil and pledge? Тому же самому программисту, из-за которого весь этот балаган нужен, потому что он неспособен не попортить память просто в силу ограничений человеческого разума? И всё это ради того, чтобы ни в коем случае не доверять эту проверку компилятору, у которого таких органичений нет в принципе?

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

138. Сообщение от nc (ok), 04-Июл-26, 00:02   –1 +/
Теперь нужно скомпилировать его с помощью gcc, затем этим скомпилированным компилятором собрать из исходников на rust компилятор Rust, и вот если этот новый компилятор двоично совпадет с оригинальным, то будет круто.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #146

139. Сообщение от Ivan_83 (ok), 04-Июл-26, 00:59   +/
> Вот ни разу никто не привёл конкретной метрики, которая позволила бы сказать, какой язык тормозной, а какой - нет.

Пользователь раньше от старости умрёт чем дождётся пока архиватор на вижалбейсике что то сделает :)


> Возьмём к примеру создание IDE. И тут, что удивительно, почему-то jvm. И не важно что это - NetBeans, Eclipse или Idea. Emacs можно вспомнить, который почему-то на Elisp-е. Опять не си.

Так кто же виноват что в вашей голове только такие примеры то?


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

Это вы про кого?
Я вообще то с вижалбейсика и начинал на х86 системах (не считая квикбейсика), постигнув его полностью и осознав его пределы я перешёл на вижал с++, и начал изучать С.

И кроме того, создавать окна с элементами точно так же можно было и в вижал с++, а потом и в res hacker утилите, а потом в схожих инструментах для гтк и наверное qt, wxwidgets...
И внутри это всё сводится к редактированию ресурсов, которые впиливаются в бинарник и которые стандартными средствами ОС превращаются в окно с элементами.


> Вы нагло врёте, даже не стесняясь. Разыменновывание nullptr - UB. При его наличии, компилятор может произвольным образом переписать код.
> Универсальность абсолютно никак не отменяет наличие UB.

Какого UB то?
Вам же написали: программист сказал прочитать/записать по адресу, язык сделал что сказали.
Язык реально не знает получится ли это сделать, тк он не анализирует код в целом и особенности платформы.
Да и в целом не важно, NULL там или какой то другой адрес - программист сам отвечает за доступность этого адреса.
Это вам не детские языки где вам попку подтирают.

Есть и более интересные случаи, когда кусок памяти может быть смаплен куданибудь в PCI устройство на регистры, и чтение/запись будет не совсем как обычно, и в случае hotplug ваще никаких гарантий... Но это для адреного кода, в основном, хотя опять же никто не запрещает смапить это и в юзерспейс процесс.

Для вас это сплошной unsafe, так жить низя - лучше идите формошлёпить :)


> Вы для начала объясните, почему если немного переписать код, расскоментировав закоментированную строку, то компилятор ВНЕЗАПНО просыпается и видит проблему?

Без понятия, откройте тикет на форуме разработчиков гцц и там спросите.


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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #141, #150

140. Сообщение от morphe (?), 04-Июл-26, 02:50   +/
А теперь попробуй написать для этого PoC
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

141. Сообщение от Аноним (131), 04-Июл-26, 03:17   +/
>Пользователь раньше от старости умрёт чем дождётся пока архиватор на вижалбейсике что то сделает :)

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

При чём тут моя голова? Вам приведён один из примеров сложного софта, который ПОЧЕМУ-ТО написан не на си. И сейчас таких примеров ПОЧЕМУ-ТО всё больше и больше.
>Это вы про кого?

Про winapi.
>Какого UB то?
>Вам же написали: программист сказал прочитать/записать по адресу, язык сделал что сказали.

Бред. Вы почему-то переносите семантику ассемблера на си. Если бы вы хотя-бы немного в этом разбирались, то такую ошибку не совершили. Упрощённый пример
int a = *b;
if (b != NULL) {
    c();
}
Будет оптимизирован до
int a = *b;
c();
В итоге, из ассемблера испаряется условный переход. И подобных моментов - куча.
>Есть и более интересные случаи, когда кусок памяти может быть смаплен куданибудь в PCI устройство на регистры

При чём здесь регистры? Вы вспоминаете все умные слова, которые знаете?
>программист сам отвечает за доступность этого адреса.

Созданием дыры? Вы и сами знаете, как программисты за что отвечают, когда в редактор автосохранение на пять минут вешают.
>Без понятия

Любое ваше сообщение как раз таки и сводится к этому "без понятия". Буквально, к этим двум словам. Ну хотя можно написать что-то вроде: "Я не согласен, ведь я без понятия, как это работает". А я, в отличии от вас, во-первых знал что такая ошибка в принципе возможна, а во-вторых, написал этот код, и как-то без фазеров и ИИ справился. Не подскажите как?
>Я то их не юзаю, наверное

Вы даже не знаете, используете их или нет, зато радостно рассказываете что и как должно быть устроено. Опять аргумент уровня: "Я не согласен, но как правильно, я не знаю".
>А вы рассказываете что по адресу NULL низя читать/писать.

Вы, как человек не знающий, что является UB, а что - нет, рассказываете о том, как компилятор будет себя вести.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #152

142. Сообщение от _ (??), 04-Июл-26, 05:04   +/
Если сильно напрягаться, то можно собрать фирмварь для Ariane-IV !
А потом на расслабоне отрефакторить в фирмварь для Ariane-V ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

143. Сообщение от Я (??), 04-Июл-26, 06:34   +/
Так это исходник растового компилятора транслирован в исходник сишного компилятора?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

144. Сообщение от Аноним (144), 04-Июл-26, 07:55   +/
Какой, интересно, размер бинарного файла после компиляции этих 46 млн строк кода на Си?
Ответить | Правка | Наверх | Cообщить модератору

145. Сообщение от Аноним (145), 04-Июл-26, 09:39   +/
Компилятор Zig тоже умеет переваривать Си, интересно сравнение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

146. Сообщение от Аноним (-), 04-Июл-26, 09:50   +/
Он не совпадет.

А вот собранный им уже крайне желательно чтоб совпал.

Оптимизаторы то могут быть разные.

А толку от компилятора с -O0 мало.

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

147. Сообщение от Аноним (147), 04-Июл-26, 12:20   +/
нафиг этот rust вообще. нужно натаскать llm какой нибудь чтобы все эти моменты проверял и все дела. в самом худшем случае стандартизировать какие нибудь #pragma чтобы в сишечке указывать то-же что и в rust
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #168

149. Сообщение от U202204161753 (?), 04-Июл-26, 14:01   +/
> В то время, как у визуал бейсика можно было создать окно, перетаскивая элементы мышкой, а c у вас ......

А у нас в Clarion всё вот это (и даже больше) было гораздо раньше.

Плюс скоростной оптимизирующий компилятор.

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

150. Сообщение от U202204161753 (?), 04-Июл-26, 14:06   +/
> Это вы про кого?

Я вообще то с вижалбейсика и начинал на х86 системах (не считая квикбейсика), постигнув его полностью и осознав его пределы я перешёл на вижал с++, и начал изучать С.


На какой конкретно из компиляторов Си/C++, если не секрет?

Многие 90 процентов времени работали на TopSpeed (он же с какого-то момента - Clarion)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #153

152. Сообщение от Ivan_83 (ok), 04-Июл-26, 14:28   +/
> Во-первых, сразу после таких громких заявлений, вам следует их подтвердить нормальными бенчмарками.

Ты в адеквате или где?
На вижалбейсике даже обычный цикл с каким нить сложением на 100к итераций будет на порядки дольше отрабатывать.
Я этого наелся ещё к 2002 году чтобы опять туда лазать. Хотя дистр VB5 у меня остался, по идее оно должно работать.


> При чём тут моя голова? Вам приведён один из примеров сложного софта, который ПОЧЕМУ-ТО написан не на си.

Притом что в вашей голове не хватило места для ещё пары десятков IDE, вики вам в помощь.


> Будет оптимизирован до

Только в ваших фантазиях.
На практике сильно зависит от компелятора и флагов.


> При чём здесь регистры? Вы вспоминаете все умные слова, которые знаете?

Вот когда начнёте с реальным железом работать - сразу узнаете причём.


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

Так другого офисного пакета у нас для вас в в 90-2000х не было.


> Любое ваше сообщение как раз таки и сводится к этому "без понятия".

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


> Вы, как человек не знающий, что является UB, а что - нет, рассказываете о том, как компилятор будет себя вести.

Успех или не успех чтения/записи по любому адресу - не зависит от компилятора, не понимаю зачем вы к нему пристаёте.
С таким же успехом можно назвать UB попытку открывать файл "/tmp/fwrgsrvsrth4a.eargwe".
Оно конечно нигде не будет определёно, но и не должно быть определено, это outofscope для компелятора.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #167

153. Сообщение от Ivan_83 (ok), 04-Июл-26, 14:32   +/
На вижуал с++, кажется первым был 6 версии, под конец я его обкладывал плагинами для отладки многопоточных приложений, ибо он сам умел показывать только стёк одного потока.
В след версии это исправили и кажется плагины мне стали не нужны.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #156

154. Сообщение от мяв (?), 04-Июл-26, 19:26   +/
неконструктивный комент
1е - "миллионы не могут ошибаться" ?
2е - нет, обман. как текстодробилку чистый шелл можно использовать и делает он это крайне быстро, заметно быстрее какого нибудь луа или питона, если писать с минимумом форков и в целом знать, какие операции сколько по времени выполняются.
3е - фантазии какието странные.
если в скрипт попадет башизм - тебе об этом скажет линтер, а условный ash пускать откажется.
за окружением - я не знаю что ты там следить собрался.
в коменте анонима фактами не пахнет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

155. Сообщение от мяв (?), 04-Июл-26, 19:28   +/
баш вполнк совместим со стандартом, опять вранье.
несоответствия должны упраздняться через опцию в set.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

156. Сообщение от U202204161753 (?), 04-Июл-26, 21:22   +/
Просто рейтинг компиляторов был таким:
1) Zortech ( в дальнейшем Digital Mars);
2) Watcom;
3) TopSpeed / Clarion.

И где-то там - Latice ( он же cl.exe / Visual Studio).

Продукция Borland - вообще вне рейтинга: оптимизация не наблюдалась. Совсем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #160

157. Сообщение от Аноним (157), 04-Июл-26, 21:23   +1 +/
>Теперь, когда люди смогли переписать компилятор раста на си (пускай и в нечитабельный код), становится ясно, что в предыдущих версиях компилятора раста не заложено

Ничего это не доказывает! Просто после трансляции, все закладки стали на Ц, но также не читаемы, так как код не читаем.

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

158. Сообщение от Аноним (157), 04-Июл-26, 21:25   +1 +/
Плюсую неистово! rust - самая толстая прога для сборки, выкинуть бы его из системы, а все что на нем, транслировать в Ц. И волки сыты и моря - холоднее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

159. Сообщение от Alladin (?), 04-Июл-26, 21:37   +/
то самое что и так работает: двойное освобождение, обращение за пределами, ..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

160. Сообщение от Ivan_83 (ok), 05-Июл-26, 00:17   +/
Это вы как то сильно заморочились видимо в производительность, и удивительно что ICC тут нет в списке. (или есть? мне названия лень гуглить :) )
Я то больше системные вещи писал и упирался в сисколы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #166

161. Сообщение от Аноним (161), 05-Июл-26, 00:24   +/
ух.. оказывается 2/3 новости не про крустц а про силли который пока только показывают но потрогать не дают ну и ладно.
Ответить | Правка | Наверх | Cообщить модератору

162. Сообщение от Талгатemail (?), 05-Июл-26, 03:50   +/
48 миллионов строк кода,
глазками посмотрю и найди все ошибки.

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

163. Сообщение от Я (??), 05-Июл-26, 06:08   +/
Подумаешь, 46 млн! Это же не 47 млн и чуть сложнее, чем 45 млн)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

165. Сообщение от Аноним (165), 05-Июл-26, 13:57   +/
> Однако для "человеческого бутстраппинга", невозможность ревью означает, что проблема доверия остается нерешенной!

Разве это проблема сегодня? Сегодня ж можно провести AI-бутстраппинг, и выполнить ревью миллионов строк кода без проблем. Ну то есть, это будет дорого, но не так дорого если платить команде программистов, которые будут десять лет перелопачивать весь код.

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

166. Сообщение от U202204161753 (?), 05-Июл-26, 20:18   +/
Да... Нет в списке...

Скорее всего, ICC - это более поздний период.

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

167. Сообщение от Аноним (131), 05-Июл-26, 23:51   +/
>Ты в адеквате или где?
>На вижалбейсике даже обычный цикл с каким нить сложением на 100к итераций будет на порядки дольше отрабатывать.

Джентльменам верят на слово? И потом, даже если ваши слова на сто процентов правдивы, то касаются они всё равно только VB. Берём https://benchmarksgame-team.pages.debian.net/benchmarksgame/... и видим, что порой самые быстрые реализации на Ocaml превосходят самые медленные реализации на Си. Берём Go https://benchmarksgame-team.pages.debian.net/benchmarksgame/... и видим аналогичную картину. У C# всё тоже не так уж плохо https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . Конечно, далеко не каждая программа будет быстрее сишной/крестовой, но никаких "на порядки" давным давно нет.
>Я этого наелся ещё к 2002 году чтобы опять туда лазать.

Ваш опыт давным давно устарел. Как минимум, в языки успели добавить целую кучу оптимизаций.
>На практике сильно зависит от компелятора и флагов.

Что, неуж-то вы всё с -O0 компилируете?
>Вот когда начнёте с реальным железом работать - сразу узнаете причём.

"Я не знаю, и по этому и вам не скажу" - идеальный аргумент. Так и веет опытом.
>Так другого офисного пакета у нас для вас в в 90-2000х не было.

Во-первых, как минимум 2007 офис так часто не падал. Во вторых, Даже если отталкиваться от 2003 оффиса, то прошло уже более 20-ти лет. Ваши представления ОПЯТЬ устарели.
>Я без понятия и меня вообще мало интересует внутренняя кухня компиляторов.

Тогда на каком основании вы вообще вставляете своё ошибочное мнение?
>Успех или не успех чтения/записи по любому адресу - не зависит от компилятора, не понимаю зачем вы к нему пристаёте.

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

Про алгебраические типы вы ОПЯТЬ не слышали. И даже сейчас, когда вам про них сказали, вы отмахнётесь от этого, сделав вид, что ничего не слышали.

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

168. Сообщение от Moloko (?), 06-Июл-26, 14:00   +/
Не думаю, что на си стоит писать в 2026 году.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

169. Сообщение от freehck (ok), 06-Июл-26, 15:32   +/
> Проект демонстрирует возможности находящегося в разработке компилятора cilly, позволяющего транслировать проекты с языка Rust на язык Си.

Мне вот интересно, а так можно будет любой Rust-проект транслировать? Просто от возможности сам rustc на неподдерживаемой платформе собрать — ни холодно, ни жарко, потому как он один фиг самостоятельно сможет собирать лишь под несколько поддерживаемых им архитектур. А вот если этот cilly сможет любой Rust-проект транслировать в си, тогда можно будет и некоторые тулзы собрать на архитектурах, отличных от Tier 1, и вот это могло бы быть полезно.

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

170. Сообщение от Аноним (170), 06-Июл-26, 15:34   +/
>В каждом лепят свои велосипеды - в итоге выхлоп шланга отличается от ЖЦЦ, а тот отличается от поделия мелкомягких.

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

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

171. Сообщение от Аноним (171), 06-Июл-26, 17:12   +/
Как мне нравятся эти попытки оправдать свою глупость задним числом, отмазками типа "это был сарказм". Вы разве не понимаете, что это выглядит ещё глупее, чем исходная глупость?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

172. Сообщение от Аноним (172), 07-Июл-26, 00:36   +/
> Думаете почему в MS Word и многих других прогах есть автосохранение какждые 5 минут?

Дед, ты когда последний раз вспоминал каким образом был организован мемори-манагемент в win16? Видимо давно, видимо поэтому ты упускаешь из виду, что когда каждое приложение должно явным образом маркировать "страницы" которые нельзя свопить, то система обречена падать каждые десять минут. Вспомни ещё, между прочим, что там кооперативная многозадачность была, и проблемы одного приложения были проблемами всех.

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

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

173. Сообщение от Facemakeremail (?), 07-Июл-26, 11:37   +/
Скорее всего нагенерировано крайне неоптимально. Я заглянул в один файл и ужаснулся:
https://github.com/FractalFir/crustc/blob/main/std/compiler/...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

174. Сообщение от Аноним (174), 09-Июл-26, 01:06   +/
План такой переписываем все написанное на Си на Rust, а потом транслируем с Rust на Си и компилируем. В результате мы молодцы - деньги освоены. Безопастность на высоте - компилить можно старыфм компилятором =)
Ответить | Правка | Наверх | Cообщить модератору


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

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




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

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