Вышла YAFL-0.30.2

Точно, надо править readme!

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

Именно так.

Для уверенности (что нет грубых ошибок в коде, что нет каких-то проблем при сборке с конкретным yafl_config.h, и тд) было бы здорово иметь автоматизированные тесты.

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

Подумаю над этим.

Доки поправил.

• https://github.com/shkolnick-kun/yafl/blob/master/README.md
• https://github.com/shkolnick-kun/yafl/blob/master/doc/C-Manual.md

Ладно, музыку шумную выравнивать :)

Ух ты, оно для выравнивания музыки подходит!

Для меня это ПВО: завязка и сопровождение цели, предсказание траектории, обнаружение маневра.

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

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

Конкретно в твоем примере можно в одном из 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); }

Аббревиатуры в camelCase следует писать только первую букву с заглавной. Например HtmlHttpWebClient. Snake_case выглядит читабельнее, но kebab-case удобнее печатать.

А где гарантия, что какой-нибудь новый 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.

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

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