LLVM. Зачем он вообще нужен?

SISAL – это гропатем (метапрог наоборот)

вебархивное: XPL A Compiler Generator contents

TMG и TWS

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

Признаками высокоуровневых языков может быть сборщик мусора, полноценная система исключений и нормальное ООП. В Расте этого нет. Там есть какие-то альтернативы, но они неполноценны, так как заставляют бороться с языком, а не думать о предметной области. В C++ этих признаков тоже нет. Ну может только ООП (фанаты какого-нибудь Смоллтолка за такие слова растерзают, но на то они и фанаты).

При наличии UB в коде скомпилированная программа может вызывать демонов,

INTERкал

PLEASE READ OUT ,1

оператор «инвольтации к эгрегору»

существенно, с какой интонацией его произносить.

иначе демоны не вызовутся, или вызовутся, да не те.

А где этого нет?

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

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

Что касается goto, то в Питоне его нет и он не нужен. То что кто-то его прикрутил показывает только то, что он шутник. Это просто что-то типа первоапрельской шутки.

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

Выход за границы массива… UB. Так что в си выхода за границы масси как раз нет :))))

в С(истянно святом) - есть только мономассив - это всё то что читаемо/писуемо через 0[смещение] остальные «массивы» это вешки баз

В стандартной библиотеке и x86 нет и вывода графики, например. А в библиотеке для x86 есть SIMD.

А нахера тебе тогда Си?

Почти гарантирует. Если есть доступ к телу функции и функция однострочник, то инлайн точно будет.

Почти? На полшишечки?

Покажи строку на LLVM.

Ну, держи.

@.str = private unnamed_addr constant [12 x i8] c"errno = %d\0A\00", align 1

; Function Attrs: noinline nounwind optnone uwtable
define dso_local i32 @main() #0 {
  %1 = alloca i32, align 4
  store i32 0, ptr %1, align 4
  %2 = call ptr @__errno_location() #3
  %3 = load i32, ptr %2, align 4
  %4 = call i32 (ptr, ...) @printf(ptr noundef @.str, i32 noundef %3)
  ret i32 0
}

declare i32 @printf(ptr noundef, ...) #1

; Function Attrs: nounwind willreturn memory(none)
declare ptr @__errno_location() #2

Нынешние glibc сделали доступ к errno через вызов функции.

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

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

Эээээ… что? Ты сейчас серьёзно аргументом против использования LLVM пытаешься притянуть то, что нужно соблюдать calling conventions платформы? Ты совсем с дуба рухнул #2?

ОС у нас POSIX. И все типы определены в сишных типах. А для LLVM надо явно указывать длину чисел в байтах (и я не уверен, что совпадает выравнивание в структурах).

Господи… ничего тупее я сегодня, кажется, уже не прочитаю.

Стандарт важен ибо промышленность индустрия и «у каждой ошибки есть фио» и прочии: разработка надёжных систем из ненадёжных элементов;кто отвечает по рекламациям и прочая ТБ

философия языка Си определяется корпусом текстов Кернигана(до golang периода хотя и golang c Томсоном живее ) и прочим соком мозга ну и прочими plan9С и NC см

unix programmer mannuals vol 1 and vol 2

ну и 2 выпуска 78(79?) и 84 года лаборатории посвящённых Си и среде его обитания Unix:

UNIX_System_Readings_and_Applications_Volume_1_1987.pdf - полная перепечатка статей из выпуска 78 года UNIX_System_Readings_and_Applications_Volume_2_1987.pdf - полная перепечатка статей из выпуска 84 года

на http://bitsavers.org/magazines/Bell_System_Technical_Journal/

ну и очевидно тьюрингова лекция Дениса Ричи ( Томсона больше вообще о фигах в карманах) -

так что карта и есть территория для карт карт

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

Ну окей. Brainfuck – это высокоуровневый язык или нет? Я серьёзно спрашиваю.

объективно в си нет массивов ( как и в питоне переменных - есть имена на объекты)

«Си-массив» это синтаксический сахар на мономассив с заданым размером элемента и смещённой базой

по факту если нет защиты по памяти

то есть один мономассив - к элементы которого определяется размерностью на что указывает указатель

т.е. в Сяшке указатель первичен - а индексность относительно типизированной вешки - синтаксический сахар более съедобный алгол(фортран_пл и проч проч)0пришельцам

Сяшка это асм - за то и

Кое-где - самый низкоуровневый :)

goto в Питоне нет во входном синтаксисе

и согласно тавтологии Бёма-Якопине оно излишне

при этом приведённый пример его прикручивания через декоратор - годный пример реализации прикручивания семантики

во времена оные был отладчик с обращениями к нему через d||

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

но Питон не требует как С++(и тем более Java) постоянно соблюдать ритуал прикручивания семантик

высокоуровневость это по началу маркетинговость подчёркивающая что менеджеру на Коболе/Бэйсике нЕ нужно регистрами обмазываться

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

+ Философия С:

https://doc.cat-v.org/plan_9/programming/c_programming_in_plan_9

goto

Бёма-Якопине

Ты еще скажи, что машины Тьюринга хватит всем

в С(истянно святом) - есть только мономассив - это всё то что читаемо/писуемо через 0[смещение] остальные «массивы» это вешки баз

Ахаха еще один не осилил прочитать стандарт. Сейчас ты путаешь указатель и массив. Это разные вещи. Ну и да — если результат смещения вышел за границы ссылаемого массива, то это тоже ub.

будь внимательней!

стандарт это для прикрытия жЁп

исторически сложилось что другого общего асма не нашлось кроме как си (ибо Юникс как универсальный пользовательский интерфейс показалось вкусным - пока wintel не за колосился)

в Си нет массивов(ты сам UB обозначил из стандарта как ожидаемое когда нарушается «декарация» массива) есть указатели

массив в языке это когда код при исполнении выдаёт не UB а детерминированное поведение при нарушении интерфейса

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

Что мешало определить поведение явно указав определённые правила (да хоть кода ошибок и аварийный останов) как например указывают правила и порядок приведения типов?

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

в Си нет массивов(ты сам UB обозначил из стандарта как ожидаемое когда нарушается «декарация» массива) есть указатели

Ещё раз: в C есть отдельно указатели и отдельно массивы. У них даже семантика разная: массив нельзя копировать, его нельзя передавать по значению, массив имеет границы, которые компилятор проверяет и дает тебе по морде если ты выходишь за эти границы (привет stack protector). Это разные сущности. То, что ты про это не ознаешь, просто означает, что ты не знаешь C.

ещёразасть это чьята «быть тугим»

в К&R(свят свят) указатель унд аррэй - одна глава

в постстандартную эпоху в tCpl ANSI/ISO/Standard approved - ужо несколько

и конечно семантика различна ибо комитет признал компиляторы разных вендоров годными а других ой-нет

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

ибо стандарт постфактум

в Си нет массивов есть сахар что бы пришелцы в указатели с первых же минут не втыкались - как результат работы хватит на много поколений вперёд ибо по забагованности С-код один из лидеров ибо знание синтаксиса не гарантирует почти ничего

какой такой чекер границы? оно явно опционально ибо без рантайма животворящего как? — зерокост не позволит чек границы

а статическое NP-(а скорее тьюринг) полно

расскажи С-писатель как вы там достигли нирваны протектируя стек!

в К&R(свят свят) указатель унд аррэй - одна глава

K&R не компилируется актуальными компиляторами. Дальше просто не о чем говорить.

UB это следсnвие унифицирующей политики уже наличных в дикой природе разросшихся реализаций за 10 лет между взрывом распространения K&R и наконец-то принятием стандрата (они не смогли в 1985 ибо тогда бы то что стало потом плюсами попало бы в стандарт - imho)

так молчи

так молчи

Нет, я буду унижать тебя и дальше.

в своей голове

зы. ты унижаешь(делаешь меньше ага) часть моего тела

в своей голове

Нет, на этом форуме. Из нас двоих – ты анскильная лалка, не осилившая C. Ты даже не знаешь что компилятор проверяет размер массива, вот умора.

царь вернулся?

унижаешь в своей голове моё (мужское) достоинство

ок.

зы. умалять чьё-либо (мужское) достоинство,

Мне всегда было интересно: ты эту шизофрению специально выдумываешь, или у тебя диагноз?

ты родился с этой мыслью?

ты родился с этой мыслью?

Вот примерно такую шизофрению, да.

Ты подебил!

Я знаю, ведь я не шизофреник.

у тебя и справка есть «не шизофреник»

у тебя и справка есть «не шизофреник»

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

удивительная осведомлённость о лицах со справкой — по началу я знал что оба собеседника не относятся к таковым

LLVM нужен для.

по началу

Ты не только C не знаешь, ты ещё и русский не знаешь.

соболезную

%2 = call ptr @__errno_location() #3 %3 = load i32, ptr %2, align 4

Это работает только на конкретной версии glibc и конкретной модели процессора.

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

Фактически, в качестве обхода везде в FFI делают что-то вроде

// ffi-errno.c
int32 ffi-errno()
{
   return errno;
}

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

И такую обвязку либо явную поддержку в коде компилятора приходится делать для любой библиотеки, интерфейс которой предоставлен макросами (например, GObject).

Ты сейчас серьёзно аргументом против использования LLVM пытаешься притянуть то, что нужно соблюдать calling conventions платформы?

То, что этот calling conventions отсутствует в LLVM и его надо велосипедить в своём трансляторе (делать что-то вроде autoconf).

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

FFI с C в любом случае требует компилятора C. Кажется, что проблемы нет.

Предлагаю обсудить, а как так получилось, что в стандарт вообще завезли UB?

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

Можно даже круче, чем brainfuck:

https://github.com/xoreaxeaxeax/movfuscator - компилятор, использующий только MOV.

FFI с C в любом случае требует компилятора C. Кажется, что проблемы нет.

Без макросов не требует. Вызов функции из разделяемой библиотеки спокойно делается и без компилятора C.

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

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

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

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

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

Скорость в ущерб надёжности в низкоуровневом языке…

Это, если посмотреть не зашоренным взглядом с критическим мышлением - не стандарт (и язык) , а какой-то кек.

Стандарты же на то и стандарты что чётко определяют как и что, разве нет? Наличие UB делает из стандарта в лучшем случае - методические рекомендации.

Скорость в ущерб надёжности в низкоуровневом языке…

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