Fil-c: Rust killer

Конвейер сломан, векторизация сломана, и это только на поверхности

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

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

Нет, я работаю в сфере HFT и по работе пишу «реал тайм» софт, хотя и soft real-time.

Я говорю, что оно не предназначено для real-time систем. Так же, как и Python. Но, несмотря на это, Python очень популярен.

Ты свой софт стандартом компилируешь?

Я пишу софт, который компилируется кем угодно компилятором по своему выбору. Предлагаешь писать не на Си, а на языке «gcc-11 c -O1»? Бывает, некоторый софт на таких языках и пишется. Но это попросту означает, что он нафарширован UB, и никто не знает, что с этим делать.

у gcc UB зависит от опций компиляции

UB - свойство программы, не зависящее от компилятора. По стандарту переполнение знакового UB. Нет в стандарте никакого «переполнения в gcc с такими-то опциями», только просто переполнение. Приводит это к эффектам или нет, это уже другой вопрос. В корректно написанной программе нельзя опираться на UB.

Ну хорошо, останемся при своём.

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

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

Т.е. кто-то думая, что вызвать unwrap – это нормально, делает такой вызов. А потом треть Интернета кукует пока Cloudflare починит сбой.

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

Повторю, важно как ведут себя конкретные компиляторы. gcc поддерживает нормальное поведение знаковой арифметики, и даже шланг поддерживает (иначе бы он никому кроме теоретиков не был бы нужен). Если компилятор такого не умеет - значит он дефективный и не надо его использовать.

Я пишу софт, который компилируется кем угодно компилятором по своему выбору

Прямо таки каким угодно? Даже компилятором фортрана? А компилятором Си из unix v4? Сейчас начнутся отмазы что это типа неправильные компиляторы, а ты говорил про правильные. А кто правильность определит?

Предлагаешь писать не на Си, а на языке «gcc-11 c -O1»

У Си много диалектов. Часть из них друг с другом взаимно несовместима. Если ты хочешь писать прогу, которая компилируется в правильно работающий бинарник (кстати, может ещё про разные платформы вспомним?) во всех из них без исключений - тебе придётся ОЧЕНЬ урезать возможности языка. Считаю такое неразумным (и думаю ты со мной согласишься). А вот дальше у нас разногласие: я считаю что разумно будет ориентироваться на имеющиеся общепринятые компиляторы, ты - на продукт чьей-то графомании, не имеющий даже референсной реализации. Понять такого не могу.

По твоему мнению,

• Нужно ли в стандарте указывать, что происходит в случае записи значения по адресу, который выходит за границы объекта?
• Нужно ли в стандарте указывать, что происходит в случае битового сдвига на >= бит, чем есть в типе? Т.е. например

  int x = 1;
  int y = x << 32;
  

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

А почему ответственный за разработку программы принимает PR с unwrap?

вызвать unwrap – это нормально

Вызвать unwrap - это нормально. Так же, как вызвать std::abort() в C++, к примеру.

Cloudflare

И какие вообще альтернативы, когда ошибка в конфигурации?

А почему ответственный за разработку программы принимает PR с unwrap?

ХЗ. Может он воспитан на примерах из обучающих материалов по Rust-у, где unwrap на unwrap-е и unwrap-ом погоняет.

А может потому, что Rust настолько хорошо спроектирован, что в нем нет исключений. Ведь исключения – это же наследие жуткого C++, поэтому фу-фу-фу.

Вызвать unwrap - это нормально. Так же, как вызвать std::abort() в C++, к примеру.

От оно чё, оказывается. Не знал. Думал, что вызов std::abort в C++ – это крайняя мера.

И какие вообще альтернативы, когда ошибка в конфигурации?

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

важно как ведут себя конкретные компиляторы

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

gcc поддерживает нормальное поведение знаковой арифметики

Допустим, со знаковой арифметикой разобрались, но что насчёт всех остальных UB?

ты говорил про правильные. А кто правильность определит?

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

У Си много диалектов. Часть из них друг с другом взаимно несовместима.

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

придётся ОЧЕНЬ урезать возможности языка

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

ХЗ. Может он воспитан на примерах из обучающих материалов по Rust-у, где unwrap на unwrap-е и unwrap-ом погоняет.

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

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

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

Ты так спрашиваешь, как будто стандартописатели собираются консультироваться у меня что им там писать. На вопросы прямо ответить не могу. Отвечу другое.

Нужно ли в стандарте указывать, что происходит в случае битового сдвига на >= бит, чем есть в типе?

На некоторых процах инструкция сдвига на чрезмерную битность оставляет от сдвига битность по модулю ширины регистра, например. А на каких-то - обнуляет регистр. В Си не принято прятать такие штуки от программиста, и соответственно оператор сдвига наследует процовое поведение. Как-то зафиксировать эту информацию, конечно, имеет смысл. Обзывать это UB - нет. Платформенно-зависимое поведение.

Нужно ли в стандарте указывать, что происходит в случае записи значения по адресу, который выходит за границы объекта?

Очевидно, при записи за границу объекта происходит запись за границу объекта. Что из этого получится - зависит от расположения объектов в памяти и от операционной системы. Язык тут в целом ни при чём.

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

Время покажет.

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

Пишу программы, которые нормально работают с нормальными компиляторами, в том числе будущими. Работу с дефективными компиляторами, чем бы они свою дефективность ни прикрывали (справками от си-комитета), гарантировать не могу.

Допустим, со знаковой арифметикой разобрались, но что насчёт всех остальных UB?

Нужен список. Но заранее скажу что многие так называемые UB на самом деле вовсе не UB, а платформо-зависимое поведение.

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

Тоже считаю что странно. Я пытался тебе разъяснить. Вот написана программа со стандартом -std=gnu89 -O0, компилировать соответственно нужно именно так.

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

Стандартов тоже много. Если ты про серию ISO Cxx, то это тоже диалекты Си. Да, они себя позиционируют как что-то высшее над диалектами, но это самоназвание и не более. И, как я уже писал, у них нет даже референсной реализации. А вот у GNU Cxx - есть (gcc). И то, что авторы шланга вынуждены, скрипя зубами, его тоже поддерживать - наглядное доказательство того, что это действительно существенная штука, а не чья-то локальная графомания.

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

См. выше, unix v4 cc твой код скорее всего не скомпилирует, значит совместимость по крайней мере с одним диалектом ты уже потерял. Осталось только выбрать приоритетный. Мой выбор на данный момент - gcc.

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

Интересно, а что является критерием «нормальности компилятора»?

На некоторых процах инструкция сдвига на чрезмерную битность оставляет от сдвига битность по модулю ширины регистра, например. А на каких-то - обнуляет регистр. В Си не принято прятать такие штуки от программиста, и соответственно оператор сдвига наследует процовое поведение. Как-то зафиксировать эту информацию, конечно, имеет смысл. Обзывать это UB - нет. Платформенно-зависимое поведение.

А вот на x86-64 обычные инструкции (sal/shl/sal/shr) берут сдвиг по модулю [кол-ва битов в ширине инструкции], а SIMD-шные расширения — зануляют при «переполнении». И мы хотим, чтобы компилятор где надо, мог использовать обычные инструкции, а где надо — SIMD-шные.

Как это описать в стандарте языка?

Очевидно, при записи за границу объекта происходит запись за границу объекта. Что из этого получится - зависит от расположения объектов в памяти и от операционной системы. Язык тут в целом ни при чём.

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

многие так называемые UB на самом деле вовсе не UB, а платформо-зависимое поведение.

Нет, UB - это то, что названо стандартом UB. Платформозависимое поведение - это unspecified behavior.

написана программа со стандартом -std=gnu89 -O0

Нет стандарта -O0, да и gnu - диалект, т.е. язык, не являющийся стандартным Си, почти вендор-лок.

unix v4 cc

Он не заявляет поддержку стандарта C23, поэтому никто от него и не ждёт компиляции современных программ.

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

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

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

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

Этот тот который позволяет не устраивать UB на ровном месте.

Как это описать в стандарте языка?

Я ж уже написал - «поведение зависит от платформы». И не надо пугать всякими UB бестолку.

Но как нужно описать такую ситуацию в стандарте, если мы уже не можем ничего гарантировать в таком случае?

Это не задача языка. Задача языка - сгенерировать машинные инструкции для выполнения запрошенного действия. Хочет программист писать за границу объекта - ок, пишем. Что будет дальше? Открывай отладчик и смотри. Это не UB. UB будет если компилятор вот этот код:

{ int a[10];
  a[11] = 5;
  printf("%d", a[11]);
  return 0;
}

{
  return 0;
}

Нет стандарта -O0, да и gnu - диалект, т.е. язык, не являющийся стандартным Си, почти вендор-лок.

Да что ж ты такой упёртый? Сколько повторять?

C23

(речь была про ISO C23, я так понимаю) это тоже ДИАЛЕКТ. Надпись «стандарт», которую авторы данного документа туда вписали - это их личное мнение, и не более того. Никакого смысла она не добавляет. Я тоже могу награфоманить хоть десяток «стандартов Си», назову их «FIRK C23», «FIRK C24», «FIRK C25», «FIRK C3000» итд. И что? В лучшем случае, это будут мои личные спецификации (если я к ним компилятор напишу), в худшем - просто бесполезные фантазии (как у ISO). Кстати, компилятор таки планирую, но с временем на него печаль.

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

Это означает, что у IE5 был стандарт html-я. Более приоритетный чем стандарты от специализированных стандартописателей. Но тут есть отличие (возможно, субъективное): IE5-ный стандарт воспринимался скорее негативно, а вот GNU C - исключительно позитивно.

Этот тот который позволяет не устраивать UB на ровном месте.

Просто образчик объективности.