http://delivery.acm.org/10.1145/2910000/2908081/p1-memarian.pdf

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

из этого можно сделать очевидный вывод: тебе с ними не по пути.

си — это макроассемблер pdp-11. если ты используешь другой процессор, то си — это сложная (и полная костылей) иллюзия того, что другие процессоры эмулируют поведение pdp-11.

Эх. Я уж было заскучал по постам скотинки.

дохлая гиперссылка, бро

прошу прощения (ох уж эти хитрожопые учёные)

https://dl.acm.org/citation.cfm?id=2908081

$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ clang test.c -fsanitize=undefined
test.c:7:50: warning: '^' within '|' [-Wbitwise-op-parentheses]
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                                            ~ ~~~^~~
test.c:7:50: note: place parentheses around the '^' expression to silence this warning
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                                                 ^
                                              (     )
test.c:7:59: warning: '^' within '|' [-Wbitwise-op-parentheses]
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                                                     ~ ~~~^~~
test.c:7:59: note: place parentheses around the '^' expression to silence this warning
                r += ((r * 20891 + *s *200) | *s ^ 4 | *s ^ 3 ) ^ (r >> 1);
                                                          ^
                                                       (     )
2 warnings generated.
$ ./a.out 
test.c:7:26: runtime error: signed integer overflow: 481340559 * 20891 cannot be represented in type 'int'
test.c:7:19: runtime error: signed integer overflow: 1752892743 + 454394588 cannot be represented in type 'int'
result: 1777607782 69f42466
result: 2147483548 7fffff9c

Теперь чиним, меняем:

int r = 0;
int foo2(int c)

unsigned r = 0;
int foo2(unsigned c)

$ ./a.out 
result: 1479383358 582d993e
result: 2147483548 7fffff9c

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

а набросить?

согласен. gcc надо переписать на golang

Стандарт мне ни стандарт яскозал!
Стандартное поведение

Ты же понимаешь, что ты поехавший?

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

Хорошая статья. Меня тут недавно пытались убедить, что в C всё просто и очевидно, а мои вопросы по стандарту говорят о том, что мне не стоит программировать.

Хотя ясно (умным людям вроде меня), что стандарт C недоопределён во многих вещах.

Знатно припекло неосилятору.

$ gcc -fsigned-char -O2 ub.c
$ ./a.out 
result: 1777607782 69f42466
result: 2147483548 7fffff9

$ gcc -funsigned-char -O2 ub.c
$ ./a.out 
result: -369875866 e9f42466
result: 2147483548 7fffff9c

На ARM'ах char беззнаковый.

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

Ищу пока [...]

Уже ведь сказали: целочисленное знаковое переполнение. Новый GCC просто лучше выражение анализирует.

Я бы отказался вообще от подобных «неясных» конструкций в коде. Никогда не знаешь, когда они выстрелят. У меня был похожий случай, на который я угробил много времени:

http://esxi.z-lab.me:666/~exl_lab/screens/unsigned_char_arm.png

Например сброс знака по (a & 0x7fffffff) не работает и много всего вообще теперь не работает и писать теперь надо как на плюсах.

У вас наверное а 64-битное и поэтому вы получаете не тот результат? Ваш код как никак подвязан к 32 битам.

Почему в 2018 не шебмкой текст? Непорядок.

Потому что злые модераторы могут сказать что это реклама и удОлить. Так и живём.

в цикле к цулому r всегда плюсуется положительное число. Компилятор сщитает что результатом работы цикла не может быть отрицательное значение в r (кроме как через переполнение которое UB). А следовательно последняя команда (r & 0x7fffffff) - лишняя так как никогда (кроме UB на которое пофиг) не меняет результат.

Вот, внятное объяснение. Непонятно, чего ещё ТС'у надо.

Компилятор сщитает что результатом работы цикла не может быть отрицательное значение в r (кроме как через переполнение которое UB).

А XOR ты не заметил?

-fsigned-char / -funsigned-char результат меняет?

Ты прав, с -funsigned-char на 7.3 нормально, на 8.1/8.2 пропадает AND: https://godbolt.org/z/tQKYqz

https://github.com/JehanneOS/devtools-kencc

А XOR ты не заметил?

Если r положителен, то (r >> 1) тоже положителен. Xor положительного с положительным не даст отрицательное число.

А я думал такие как ты только в байках бывают.

Да ты прав.

кроме как через переполнение которое UB

целочисленное переполнение всегда Defined и весьма хорошо задокументированное поведение. На Лоре Это уже обсуждалось.

Это относится только к беззнаковым целым.

на X86 и ARM это односится ко всем целым. Есть железо где это не так, но я даже затрудняюсь вспомнить название архитектуры.

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

Понятно, что и знаковое, и беззнаковое компилируются в один и тот же код в случае, если знаковое - это 2's complement. Не определена именно семантика переполнения знаковых целых в языке Си.

Не нашёл ни одного источника, который бы это подтверждал. Везде написано, что по стандарту signed overflow == UB. И заодно, как архитектура связана с переполнением? Разве не авторы компилятора решают что делать в той или иной ситуации?

Проблема в том что у GCC под ARM по непонятным для меня причинам сhar - беззнаковый (0-255).

Я где-то читал, что беззнаковый char был сделан в угоду производительности на старых ARM'ах. Но, возможно, есть какие-либо другие причины.

Наверное я попутал стандарты языка и документацию на процессоры.

И заодно, как архитектура связана с переполнением?

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

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

В случае С/С++/Ада - нет. В случае матлаб или октавы - да.

Ты имеешь ввиду что 2's complement не прописан собственно в стандарте языка?

Хм ... Наверное так и есть ...

Я, конечно, не сишник, но

страшно бояться любого UB так как оно будет страшно падать на ровном месте

- это разве не универсально здравый смысл?

Чувак, даже шестой gcc — говно! Потому как компиляющийся ранее безо всяких ошибок код в gcc начинает срать насчет всяких «трамплинов» и т.п. И приходится как минимум добавлять в Makefile ключ -Wno-trampolines. Иначе как ты вложенные функции сделаешь?

Компилятор должен просто компилировать то, что ему написали. Если он начинает вертеть носом, то это не компилятор, а говно!

Любая система, которая не позволяет мне выстрелить себе в ногу, является по умолчанию говном. Потому что нафиг мне эти ограничения? Эдак в мастдайку какую-нибудь скатиться можно...

Вложенные функции? Мы точно про си, а не про питон тут?

Если я правильно помню то их даже в стандарт добавили

Когда? В который? Мне тут говорят что нельзя было ещё в прошлом году https://www.quora.com/How-is-it-possible-to-perform-a-nested-function-in-C/an...

https://stackoverflow.com/questions/2608158/nested-function-in-c/2608167#2608167

Какой сейчас более-менее адекватный gcc, 5.4?

2.95?

А свой компилятор не хочешь написать?

Тут надо заглянуть в С11. На 100 процентов не уверен, но мне казалось что это в конце концов туда внесли

2.95?

Нет - 2.95.3 :-)

Хотя на самом деле это тоже было какоето недоразумение. Я уже не помню почему ...

существуют три основных двоичных представления знаковых чисел.

На сколько я понял, именно поэтому когда-то переполнение знакового и сделали UB.

В случае С/С++/Ада - нет. В случае матлаб или октавы - да.

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

Автору просто нужно компилять весь свой код с -fwrapv и прочими -f, так любимыми Линусом Торвальдсом.

в с++20 это собираются починить:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html

перешёл c 86-64 на Ъ 64-битную архитектуру и всё сломалось, ну или наоборот, даунгрейд до 16 бит

Что ж ты будешь делоц, если у тебя sizeof(int) != 4 вылезет?

А видел ли кто этот стандарт? Жадные твари из ISO хотят за текст стандарта деньги, и я не знаю никого кто бы его купил. Может там всё совсем иначе чем в драфтах?