Вышла YAFL-0.30.2

Откуда ты узнал? Я тут этого не писал.

В этом топике не писал, а на ЛОРе где-то писал.

Нет. Просто нет лишних надписей «int».

Я поэтому и не хотел вступать в спор, просто указав, что так больше никто не делает. О чём спорить, если ты на аргумент (spooky action at distance универсально считается чем-то плохим в программировании, а ты выступаешь за spooky action at distance, только в пределах одной функции) говоришь просто «нет»? Ну нет — так нет.

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

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

Нельзя, это undefined behavior (дал ссылку на перечисление выше).

Нет, можно. Не надо врать. Или приведи мне пруфы

Тезис: согласно стандарту, определение макроса, имя которого совпадает с ключевым словом, является undefined behavior. Иными словами, согласно стандарту, программа, в которой написано #define int float, может сделать что угодно.

Тезис: использование undefined behavior считается плохой практикой. Код, полагающийся на это, может сломаться при переходе от одной версии компилятора к другой. Примером может служить signed overflow. Когда-то не существовало компиляторов, на которых код со знаковым переполнением мог сломаться. Однако это всё ещё было undefined behavior и так делать не следовало.

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

spooky action at distance универсально считается чем-то плохим в программировании

Я вот плохим считаю необоснованные надписи на непонятных языках. А эта штука, чем бы она ни была, не «универсально считается» а «тобой считается», ну и ещё кем-то. Не пиши за всех. Ну и уточни по-русски что ты имел ввиду.

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

Это был риторический вопрос. Ответ на него в следующей же фразе.

Тезис: согласно стандарту

А я тебе опять повторю: отвлекись от этой графомании, в которой может быть написано что угодно, и посмотри на реальные компиляторы. Реальные компиляторы нигде не нарушают абстракцию под названием «препроцессор», а у препроцессора ключевое слово всего одно - defined. Всё остальное для него - идентификаторы, равноправные (а если не использовать #if - то просто токены, и даже defined - уже не ключевое слово). Строчка #define int float означает, что во всём последующем тексте токен int следует заменить на токен float, что и будет безусловно сделано.

Код, полагающийся на это, может сломаться при переходе от одной версии компилятора к другой

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

Примером может служить signed overflow.

Это как раз пример того, что компилятор надо настраивать под нужды программиста - там есть опции -fstrict-overflow, -fwrapv, описанные в мануале.

С каким их этих тезисов ты будешь спорить?

Ты неявно вплёл в них третий: авторитетным источником понятия undefined behaviour является С-комитет. Вот этот тезис и есть корень проблем.

Я вот плохим считаю необоснованные надписи на непонятных языках.

Английский — непонятный язык. ОК.

А эта штука, чем бы она ни была, не «универсально считается» а «тобой считается», ну и ещё кем-то. Не пиши за всех. Ну и уточни по-русски что ты имел ввиду.

https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming)

Google Translate в помощь, если непонятно. Глобальные переменные там тоже упоминаются.

Это был риторический вопрос. Ответ на него в следующей же фразе.

И к чему мы пришли-то? Я сказал, что _X является зарезервированным идентификатором. Ты в ответ написал, что _X писать компилятор «не мешает». Не мешает, но если так напишешь, то гарантии на то, что получится, нету, поскольку любые зарезервированные идентификаторы могут использоваться компилятором и реализацией. Так?

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

{{Citation needed}}. Можешь показать хоть один проект, который заявляет «да, у нас тут непортируемый код, его нужно собирать обязательно вот этой версией вот этого компилятора вот с такими опциями»?

Ты неявно вплёл в них третий: авторитетным источником понятия undefined behaviour является С-комитет. Вот этот тезис и есть корень проблем.

Кто ещё может являться авторитетным источником этого понятия? Разработчики компиляторов? Я что-то не видел, чтобы они публиковали какой-то альтернативный стандарт.

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

Google Translate

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

Не мешает, но если так напишешь, то гарантии на то, что получится, нету

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

реализацией

Что это такое вообще?

{{Citation needed}}

Твой же пример с signed overflow.

Можешь показать хоть один проект

Опять ты за своё...

Кто ещё может являться авторитетным источником этого понятия?

Мануал к компилятору.

Я что-то не видел, чтобы они публиковали

Ну, протри глаза, у gcc есть большой мануал с описанием его поведения в зависимости от опций.

И ты по факту споришь со вторым тезисом

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

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

Я, значит, должен сам перевести эту статью на русский язык для тебя? Или скопипастить то, что выдаёт Google Translate? Или скопипастить английский текст? Я не понимаю. “Action at a distance” означает «действие на расстоянии». Что это такое и почему это антипаттерн, там рассказывается.

Гарантии и так и так нет.

Почему нету?

#define X
int main(void)
{
}

#define _X
int main(void)
{
}

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

Если эта версия будет соблюдать тот же стандарт, то не могут. В стандарте указано, какие идентификаторы — зарезервированные, все остальные можно использовать. Если какой-то из них нельзя, то реализация компилятора не conforming.

реализацией

Что это такое вообще?

В данном случае это означает «стандартная библиотека и прочие кишки, необходимые для запуска conforming программ на Си». Я уже приводил в пример символы _GLOBAL_OFFSET_TABLE_ и _IO_stdin_used (они начинаются с _X, по-другому быть не могло).

> Кто ещё может являться авторитетным источником этого понятия?

Мануал к компилятору.

> Я что-то не видел, чтобы они публиковали

Ну, протри глаза, у gcc есть большой мануал с описанием его поведения в зависимости от опций.

> И ты по факту споришь со вторым тезисом

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

Интересно. Значит, есть «мануал» или «спецификации конкретного компилятора». Но эти документы ссылаются на сишный стандарт, иногда только говоря, что в этом случае то или иное поведение становится определено. А где там написано, что можно определять _X?

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

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

с точки зрения стандарта

Вот вырежи эту фразу, иначе смысла нет.

А на поведение этой — нету

Шанс поломки этих программ примерно одинаковый. И он вовсе не из-за названия переменной (шанс того, что займут кейвордом _X - такой же нулевой, как и то, что займут X), а из-за того что где-то в будущем авторы компиляторов могут решить что int main() без return это ошибка. Или из-за того что переменная объявлена но не используется, а у компилятора в скрипте сборки включён -Werror=unused или как его там.

В данном случае это означает «стандартная библиотека и прочие кишки, необходимые для запуска conforming программ на Си».

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

Но эти документы ссылаются на сишный стандарт

Только в информационном плане. Точно так же мануал от шланга неявно ссылается на мануал от gcc, когда описывает свои флаги для компиляции программ на GNU C.

Ну и вот смотри:

https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/Optimize-Options.html#index-fstr...

никаких отсылок на C89/C99/C11 тут нет, чисто описание опции. А именно: она делает signed переполнение неопределённым для того, чтобы оптимизатор мог лучше работать. Обрати внимание, что это вовсе не дефолт, а именно опция, которую надо явно включать, этим флагом или -O.

А где там написано, что можно определять _X?

Это само собой подразумевается. Там ещё нигде не написано, что можно определять X. Или что можно определять Y.

если ты на аргумент (spooky action at distance

Каким боком объявление переменной в начале блока кода позволяет одному блоку программы влиять на другой?

Предположим, у нас есть две программы

{
   int i;
   ...
   for(i = 1; i <= n; i++) ...
   ...
   for(i = 100; i <= k; i++) ...
   ...
   for(i = 5; i <= 20; i++) ...
   ...
}   

и

{
   ...
   for(int i = 1; i <= n; i++) ...
   ...
   for(int i = 100; i <= k; i++) ...
   ...
   for(int i = 5; i <= 20; i++) ...
   ...
}   

Что такого spooky можно сделать в первой и нельзя во второй?

Каким боком объявление переменной в начале блока кода позволяет одному блоку программы влиять на другой?

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

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

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

Конкретно в твоем примере можно в одном из for-ов забыть заново инициализировать переменную.

Если забыть инициализировать вновь объявленную будет ещё хуже. Тогда UB будет. А так хоть тест гарантированно ошибку найдёт.

Если забыть инициализировать вновь объявленную будет ещё хуже.

Только сделать это сложнее.

Тогда UB будет

Будет 100% ругань от статического анализатора, в отличие от.

Нежелательно использование значений глобальных переменных.

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

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

Я же привёл пример. Глобальное значение не используется, в каждом цикле переменная инициализируется заново.

Будет 100% ругань от статического анализатора, в отличие от.

Ну разве что. Хотя статический анализатор на

for(;i<=100;i++)

также заругается, как и на

for(int i;i<=100;i++)

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

Например, в любом коде на Си есть глобальная переменная errno. Используется не всегда.

И что плохого в использовании значения errno?

Это же глобальная переменная! А значит spooky action at distance! Обязательно надо переделать всё так, чтобы создавалась новая локальная errno перед каждым вызовом!

Краткое содержание предыдущих серий:

- По стандарту так делать нельзя.

- Стандарт мне не указ! Там сидят графоманы и террористы! Так делать МОЖНО, я гарантирую это!

- А кто тебе указ?

- Мануалы и спецификации конкретного компилятора.

- Но они ссылаются на сишный стандарт как на основу, и в них дополнительно нигде не написано, что так делать можно…

И вот мы видим новое заявление: некая вещь («так делать можно»), оказывается, сама собой подразумевается (никаких цитат из документа не приведено) в документе, который ссылается как на основу на другой документ, в котором написана вещь прямо противоположная («так делать нельзя»).

В общем, мда. Предлагаю либо найти в «мануале и спецификации конкретного компилятора» альтернативные (тем, которые описаны в стандарте Си) правила для идентификаторов, либо прекращать этот цирк.

Вроде бы сейчас никто не спорит, что errno было ошибкой. Линус тоже так считает: https://yarchive.net/comp/linux/errno.html

Но они ссылаются на сишный стандарт как на основу, и в них дополнительно нигде не написано, что так делать можно…

Это не отсылка как на основу, а пояснения для стандарто-фанатиков, в политкорректной форме.

В общем, мда. Предлагаю либо найти в «мануале и спецификации конкретного компилятора» альтернативные правила для идентификаторов, либо прекращать этот цирк.

Цирк тут устраиваешь ты. Правила для идентификаторов (не альтернативные, а как раз основные) - содержать [_A-Za-z0-9], не начинаться с цифры и не совпадать с ключевыми словами. Правила для токенов-идентификаторов препроцессора - такие же, но без правила про ключевые слова. По факту компиляторы могут поддерживать больше, например gcc допускает символ $ в именах. Возможно где-то поддерживается произвольный юникод с кодами 0x80 и выше.

А вот спецификация кстати: https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Identifiers

Это не отсылка как на основу, а пояснения для стандарто-фанатиков.

Это ссылка на основу, поскольку эти «мануалы и спецификации конкретного компилятора» не описывают математически язык, который компилируется. А стандарт — описывает. И компилятор декларирует, что он соответствует стандарту, с некоторыми исключениями:

For each language compiled by GCC for which there is a standard, GCC attempts to follow one or more versions of that standard, possibly with some exceptions, and possibly with some extensions.

Цирк тут устраиваешь ты. Правила для идентификаторов - содержать [_A-Za-z0-9], не начинаться с цифры и не совпадать с ключевыми словами. Правила для токенов-идентификаторов препроцессора - такие же, но без правила про ключевые слова. По факту компиляторы могут поддерживать больше, например gcc допускает символ $ в именах.

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

Это ссылка на основу,

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

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

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

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

Я тебе даже могу продемонстрировать, что Clang считает, что так делать не следует. Из этого видимо должно следовать, что, согласно «мануалу и спецификации конкретного компилятора» Clang такая вещь не разрешается.

$ cat foo.c
#define _X
int main()
{
}
$ clang -Wreserved-identifier foo.c
foo.c:1:9: warning: macro name is a reserved identifier [-Wreserved-macro-identifier]
#define _X
        ^
1 warning generated.

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

int main(unsigned int argc, char **argv)

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

Ссылку я привёл.

Это какая-то бульварная проза. Например, там написано, что не стоит использовать суффикс _t для типов:

When selecting names for types, you should avoid ending your type names with a _t suffix. The compiler will allow you to do this, but the POSIX standard reserves use of the _t suffix for standard library type names.

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

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

Это части реализации, очевидно же. А моя программа — нет.

Это какая-то бульварная проза. Например, там написано, что не стоит использовать суффикс _t для типов:

Ух ты, как интересно. Ну, хочу тебе объявить, что ты попался в свою же «ловушку». Т.к. эта штука ровно из той же серии что и про идентификаторы, начинающиеся с подчёркивания - «зарезервировано для стандартной библиотеки» по версии POSIX (стандарт кстати более значимый чем C99, если мы говорим именно про библиотеку). Только одна мелочь - тут не сказано «запрещено», тут сказано «нежелательно».

Это части реализации, очевидно же. А моя программа — нет.

Ты опять этот мутный псевдотермин приплетаешь. Для компиляции libc другой Си используется что ли? А если у меня своё libc, то там какой язык будет - с разрешённым _ или нет? Язык один и тот же, правила одни и те же. Можно написать «зарезервировано для библиотеки» как с _t сделали, но это не запрет а рекомендация.

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

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

В случае Си/Си++ основной функцией стандарта является указание, какой код компилятор может невозбранно превращать в что угодно(потому что в этом коде есть UB).

Если про конкретный компилятор известно, например, что в нём разыменование нуля не UB (почти все компиляторы C для DOS), то его можно спокойно использовать.

По стандарту ничего, если ты вдруг с бодуна не решишь туда что-то записать. А так, насколько помню, errno является ‘thread local’ и вполне нормально обрабатывать его внутри потока.

Записывать тоже никто не запрещает. Более того, тот же libc это делает прямо таки постоянно.

с бодуна

Это не с бодуна, а штатное её использование - вернуть код ошибки одновременно с возвратом -1 или чего-то подобного. Типа такого: errno = EINVAL; return -1;. Или такого: errno_save=errno; do_cleanup(); errno=errno_save; return -1; чтобы очистительные процедуры не испортили содержимое кода ошибки.

вполне нормально обрабатывать его внутри потока.

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

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

У Rust нет стандарта и там из какой-либо официальной документации невозможно понять, например, что делает битовый сдвиг влево при shift_amount >= bit_width. А из стандарта Си можно понять — это undefined behavior. Вот зачем нужен стандарт.

Я перестал понимать, где у нас расхождения в конкретных фактах. Происходит какой-то спор ради спора. С каким именно моим утверждением ты споришь?

С тем, что C89/C99/C11 это главный первоисточник по вопросам того, что такое Си.

например, что делает битовый сдвиг влево при shift_amount >= bit_width

То, что указано в реализации трейта std::ops::Shl для заданного типа. Возвращает для типа T значение типа Shl<T>::Output.

Для стандартных типов поведение описано в https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md

А из стандарта Си можно понять — это undefined behavior.

А из документации Rust можно понять, что там нет undefined behavior.

Как из стандарта Си понять, что выведет код

int x = 40000;
if(x*2 < 0) printf("minus"); else printf("ok");

?

Для стандартных типов поведение описано в https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md

Summary

Change the semantics of the built-in fixed-size integer types from being defined as wrapping around on overflow to it being considered a program error (but not undefined behavior in the C sense).

Т.е. этот RFC меняет поведение, которое было ранее определено (арифметика по модулю) на «либо по модулю, либо падаем». А где гарантия, что какой-нибудь новый RFC это снова не поменяет завтра?

Как из стандарта Си понять, что выведет код

Я не понимаю, что ты хочешь этим сказать. Стандарт определяет понятие strictly conforming программ — это программы, поведение которых одинаково при любой реализациии стандарта. Эта программа (если додумать main) не strictly conforming, поскольку существует реализация, под которой она являет undefined behavior. А ещё существует реализация, под которой её поведение определено. С таким же успехом можно спросить, что сделает код

fn main() { println!("{}", std::usize::MAX); }

fn main() { println!("{}", 1u32 << 32u32); }

А где гарантия, что какой-нибудь новый RFC это снова не поменяет завтра?

В C++ тоже auto сейчас обозначает совсем не то, что в первой версии. Языки развиваются.

Эта программа (если додумать main) не strictly conforming, поскольку существует реализация, под которой она являет undefined behavior.

Хорошо. Вот без UB:

#include <stdio.h>
int main()
{
  unsigned x = 40000;
  unsigned y = 2 * x;
  if(y < x) printf("over"); else printf("ok");
  return 0;
}

fn main() { println!(«{}», std::usize::MAX); }

Выведет значение константы.

fn main() { println!(«{}», 1u32 << 32u32); }

Вызовет панику.

В C++ тоже auto сейчас обозначает совсем не то, что в первой версии. Языки развиваются.

Только вот если я пишу под какой-то определёныый стандарт, то он уже не поменяется. А у Rust есть какие-нибудь версии языка, для которых этот RFC уже точно не «отменят»?

Хорошо. Вот без UB:

Зависит от реализации (сколько бит в unsigned int). Тоже не является strictly conforming. В чём проблема и что ты хочешь сказать? Поведение

fn main() { println!("{}", std::usize::MAX > 4294967296); }

Выведет значение константы.

Которое зависит от реализации.

fn main() { println!(«{}», 1u32 << 32u32); }

Вызовет панику.

Ха-ха, нет. Ты сам не читал это своё RFC? Поведение зависит от того, компилируешь ли ты с release или debug. В release оно выведет 1, а в debug упадёт.

А у Rust есть какие-нибудь версии языка, для которых этот RFC уже точно не «отменят»?

Все, которые на данный момент вышли после того RFC.

В чём проблема и что ты хочешь сказать?

В том, что -1 << 32 тоже может зависеть от реализации и это нормально.

В release оно выведет 1, а в debug упадёт.

Подловил. Я не настоящий сварщик. Я на Racket пишу, а не на Rust.

Все, которые на данный момент вышли после того RFC.

Понятно, эти версии называются “Editions”. Ну тогда я был не прав. Но найти этот RFC непосвящённому человеку довольно сложно.

В том, что -1 << 32 тоже может зависеть от реализации и это нормально.

Моя позиция как раз в этом и заключается.

Тогда я не понял тезиса из сообщения Вышла YAFL-0.30.2 (комментарий)

Предположим, что этого RFC нет вообще. Значит просто нет гарантий, что поведение на ошибочные данные сохранится в следующих версиях. Также как для Си нет гарантий, что 80000 переполнит int.

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

В целом, стандарт не даёт никаких преимуществ перед документацией на компилятор, если не предполагается переход на другой компилятор. Более того, текущая версия компилятора может не полностью поддерживать стандарт и тогда вообще надо смотреть только документацию на компилятор.