KISS языки

> 2. Арифметика по модулю 2^N при переполнении знаковых целых.

По _КАКОМУ_ N? По N без учета знакового бита или с учётом? Или опять какого-то астрального N?

1. Чтобы обосновать, что «прибитие гвоздями» в данном случае влечет хоть какие-то проблемы.

А это надо обосновывать? Ты гарантируешь, что, каждая существующая или созданнная в будущем аппаратная платформа имеет и будет иметь одну и ту же _эффективную_ арифметику по модулю для _любого_ целочисленного знакового типа С?

> По _КАКОМУ_ N?

sizeof(int) * 8

А это надо обосновывать?

Да. На заре компьютерной эры, наверное, не все использовали дополнительный код... Но эти времена давно прошли.

_эффективную_ арифметику по модулю для _любого_ целочисленного знакового типа С

Достаточно только для типов int и unsigned.

каждая существующая или созданнная в будущем аппаратная платформа имеет и будет иметь одну и ту же _эффективную_ арифметику

Для начала огласи все-таки перечень современных популярных архитектур, которые этой арифметики не имеют? Зачем бороться с проблемой, которой де-факто попросту не существует?

> sizeof(int) * 8

Достаточно только для типов int и unsigned.

1. Хренассе ?!? Т.е. signed char, signed long, signed long long могут вести себя иначе чем signed int? Спасибо, пользуйтесь сами.

2. Каких еще int и unsigned? UB при переполнении только signed типов и типов без знака. Для unsigned никакого UB нет.

Для начала огласи все-таки перечень современных популярных

Ну не хрена себе условия. Т.е. если архитектура не соверменная или не популярная, то не видать ей, убогой, компилятора С соответсвующего стандарту?

Зачем бороться с проблемой, которой де-факто попросту не существует?

Т.е. проблемы арфиметического переполнения в современных компьютерах нет? Чего только не узнаешь на ЛОРе...

> типов без знака.

типов без явного указания знака.

> Хренассе ?!? Т.е. signed char, signed long, signed long long могут вести себя иначе чем signed int? Спасибо, пользуйтесь сами.

Бггг. Ну иди прочитай про integer promotion в стандарте.

Ну не хрена себе условия. Т.е. если архитектура не соверменная или не популярная, то не видать ей, убогой, компилятора С соответсвующего стандарту?

А если она не двоичная, а троичная или семиричная? А если у нее в байте 5 бит? Вот и отказ от допольнительного кода - из той же серии. Натягивать мейнстрим на _такую_ маргинальщину — это просто маразм.

Т.е. проблемы арфиметического переполнения в современных компьютерах нет? Чего только не узнаешь на ЛОРе...

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

> Ну иди прочитай про integer promotion в стандарте.

При чём тут integer promotion? Ты точно понимаешь смысл этого выражения?

Выходи к доске и рассказывай всему классу, какое он имеет отношение к переполенению целых. Можешь на примере int и signed char.

Вот и отказ от допольнительного кода - из той же серии. Натягивать мейнстрим на _такую_ маргинальщину

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

Передернул, молодец.

Ты дурак? Проблема, которой по твоему мнению нет, называется «арифметическим переполнением». В стандарте С она решена определенным образом по двести лет как всем известным причинам.

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

Поскольку предыдущих N постов тебе оказалось не достаточно, чтобы что-то понять, то конкретно для тебя я «по сути» вообще ничего не скажу. Бесполезно напевать мелодию глухому.

> Ты дурак? Проблема, которой по твоему мнению нет, называется «арифметическим переполнением».

Да неужели? А я-то думал, проблема не в переполнении, а во взявшемся с какого-то бодуна UB.

В стандарте С она решена определенным образом

В стандарте Си проблема не решена.

Для любителей натянутого мейнтсрима на не маргинальщину есть Java и дотнет

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

Бесполезно напевать мелодию глухому.

Особенно когда глухой старательно прикидывается идиотом, да? .)

Хренассе ?!? Т.е. signed char, signed long, signed long long могут вести себя иначе чем signed int? Спасибо, пользуйтесь сами.

Ну иди прочитай про integer promotion в стандарте.

При чём тут integer promotion? Ты точно понимаешь смысл этого выражения? Выходи к доске и рассказывай всему классу, какое он имеет отношение к переполенению целых. Можешь на примере int и signed char.

Объясняю для тех, кто прогуливал уроки. Никакого собственного поведения в смысле арифметики у signed char нет. Перед выполнением арифметической операции signed char кастуется к int, затем над int выполняется арифметика.

>> По _КАКОМУ_ N?

sizeof(int) * 8

так, видимо, не годится — емнип есть архитектуры, где int и char оба по 32 бита

правильный ответ — что такое N существует, и является константой для данного процессора и данного типа целых чисел

если кому приспичит, то можно и определить например как N = 1 + log_2(-INT_MIN_VALUE) или как оно там в си

> Перед выполнением арифметической операции signed char кастуется к int, затем над int выполняется арифметика.

Ололо!!

Именно этого ответа я и ждал. )))

Примечание мелким текстом, ты, о посещающий уроки, конечно же не читал? ;))


The integer promotions are applied only: as part of the usual arithmetic conversions, to certain
argument expressions, to the operands of the unary +, -, and ~ operators, and to both operands of the
shift operators, as specified by their respective subclauses.

Перевести? ;))

> правильный ответ — что такое N существует, и является константой для данного процессора и данного типа целых чисел

Остался последний шаг - допустить, что отрицательные числа могут быть не представлены дополнительным кодом, и мы получим то, что есть. ;)))

> допустить, что отрицательные числа могут быть не представлены дополнительным кодом

С какого бодуна это нужно допускать?

> Именно этого ответа я и ждал. ))) Примечание мелким текстом, ты, о посещающий уроки, конечно же не читал? ;))

А теперь читаем ISO/IEC 9899:TC2

§5.1.2.3

EXAMPLE 2 10 In executing the fragment char c1, c2; /* ... */ c1 = c1 + c2; the ‘‘integer promotions’’ require that the abstract machine promote the value of each variable to int size and then add the two ints and truncate the sum. Provided the addition of two chars can be done without overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only produce the same result, possibly omitting the promotions.

Ы? Дальше - читаем

§6.3.1.8 Usual arithmetic conversions

.... the integer promotions are performed on both operands.

§6.5.6 Additive operators

If both operands have arithmetic type, the usual arithmetic conversions are performed on them.

> Перевести? ;))

Объясняю: к операндам «of the unary +, -, and ~ operators, and to both operands of the shift operators» применения «Usual arithmetic conversions» не производится. Тем не менее, к ним все равно производится применение «integer promotions».

Да, ты прав, признаю. )))

Теперь вернёмся к главной теме срача:

С какого бодуна это нужно допускать?

А с какого это нужно исключать? ;))

> А с какого это нужно исключать? ;))

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

Ок, зайдем с другого конца.

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

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

мы все ждем-недождемся, когда ты представишь нам процессор, где отрицательные числа не представлены дополнительным кодом — вместе со ссылкой на сайт фирмы-производителя, которая его продает

ну или хотя бы продавала 10 лет назад.

> так, видимо, не годится — емнип есть архитектуры, где int и char оба по 32 бита

Угу, с восьмеркой я здорово погорячился.

> Какую волшебную семантику ты хочешь повесить на превращение операций над двумя знаковыми величинами в операции по модулю N?

Скажем, мне нужно взять сумму 100 слагаемых. Причем я точно знаю, что значение этой суммы лежит между INT_MIN и INT_MAX. В случае Си я не могу просто взять и бездумно слагаемые просуммировать. Потому что где-то на пол-пути может случиться переполнение и UB.

> Скажем, мне нужно взять сумму 100 слагаемых.

Это не ответ на вопрос. Переполнение может случится с любыми данными. Вопрос был, какую семантику ты хочешь повесить на переполнение _знаковых_ переменных? Чему должно быть равно INT_MIN - 1 и почему?

> Вопрос был, какую семантику ты хочешь повесить на переполнение _знаковых_ переменных?

Я уже привел тебе частный случай: нужно, чтобы в процессе вычислений оно имело право переполниться, а затем переполниться в обратную сторону. Переполнения взаимно уничтожаются, и в итоге получаем корректный ответ. Вот такая семантика. Процессоры это делать позволяют, а Си - нет.

Чему должно быть равно INT_MIN - 1 и почему?

Ты про кольца вычетов слышал когда-нибудь?




Да и не в этом суть претензий к Си. Суть претензий хорошо сформулировал www_linux_org_ru: http://www.linux.org.ru/jump-message.jsp?msgid=5163288&cid=5164527

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

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

> Вопрос был, какую семантику ты хочешь повесить на переполнение _знаковых_ переменных? Чему должно быть равно INT_MIN - 1 и почему?

ты вообще разобрался с двоичным дополнительным кодом?

З.Ы. INT_MIN-1 == INT_MAX

например, -128-1=+127

> И весь этот хаос пожирает лютое, невообразимое количество человеческого труда.

Если под «хаосом» подразумевается положение с целочисленной арифметикой, то твои слова - бред.

> Если под «хаосом» подразумевается положение с целочисленной арифметикой, то твои слова - бред.

Не только с арифметикой, к сожалению.

Разработчики ядра какое-то время назад собирались писать свой комплятор Си (даже новость на главной была, емпин), потому что поведение gcc (который пытается строго соответствовать Стандарту) их не устраивало.

http://lkml.org/lkml/2009/4/22/78

Ingo Molnar

In the past 15 years of Linux we've invested a lot of time and effort into working around and dealing with compiler crap. We wasted a lot of opportunities waiting years for sane compiler features to show up. We might as well have invested that effort into building our own compiler and could stop bothering about externalities. The Linux kernel project certainly involves the right kind of people who could make something like this happen.

...

Since most of the performance-critical code in Linux is hand-optimized already, we dont even need all that many complex, exotic optimizations - we want to encourage common-sense coding practices.

это интересно

оно вылилось в некий список того, каким они хотят видеть си и компилятор?

Не знаю, не следил за этим.

> поведение gcc (который пытается строго соответствовать Стандарту) их не устраивало.

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

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

Если под «хаосом» подразумевается положение с целочисленной арифметикой, то твои слова - бред.

вот попробуй перед запуском предскажи, что напечатает вот это:

#include <stdio.h> 

int main()
{
    unsigned char c=1,b=1;
    c=(c+~c)/2;
    b=(b+~b)>>1;
    printf("c=%d b=%d\n", (int)c, (int)b );
    return 0;
}

spoiler: gcc -fdump-tree-all и дальше смотрим gimple

> Впрочем, если бы они и написали свой компилятор, не думаю, что результат был бы сколь-нибудь лучше gcc.

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

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

> если бы они взялись писать компилятор на си, то у них бы получилось что-то вроде gcc, не лучше

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

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

У «них» хватило ума не писать свой компилятор.

> Я уже привел тебе частный случай: нужно, чтобы в процессе вычислений оно имело право переполниться, а затем переполниться в обратную сторону. Переполнения взаимно уничтожаются, и в итоге получаем корректный ответ. Вот такая семантика.

Это семантика unsigned. Она _уже_ есть. Вопрос по прежнему остается - зачем тебе та же самая семантика в signed?

Ты сам в этом только что убедился на примере своей ошибки с integer promotion.

Где? У меня нет на руках С99/С89, но готов поспорить, что это - бэкпорт из плюсов. Эта абстрактная конструкция никак не влияет арифметику чаров. Приведи хоть один случай, когда бы эта часть стандарта повлияла на реальную работу программы.

Да и не в этом суть претензий к Си. Суть претензий хорошо сформулировал www_linux_org_ru

Да какая же это «прентезия»? В этом:

требуется быть параноиком и исходить из того, что НИЧЕГО ДЕЛАТЬ НЕЛЬЗЯ, кроме того, что в явном виде разрешено стандартом;

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

И весь этот хаос пожирает лютое, невообразимое количество человеческого труда.

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

Впустую, просто из-за того, что язык такой запутанный.

Это «впустую» состоит из POSIX, сокетов, TCP/IP, HTTP, и даже HTML/XML наконец.

> INT_MIN-1 == INT_MAX

См. выше.

ты вообще разобрался с двоичным дополнительным кодом?

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

> целочисленный отрицательный нуль

Ты в курсе, что нуль (нейтральный элемент по сложению) у целых чисел - единственен? Положительный, отрицательный, теплый, мягкий, а также зелёный в крапинку нули друг от друга неотличимы.

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

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

Вопрос снят, Влор привел такой пример:

http://www.linux.org.ru/jump-message.jsp?msgid=5163288&cid=5168649

> Это семантика unsigned. Она _уже_ есть. Вопрос по прежнему остается - зачем тебе та же самая семантика в signed?

Пример также остается в силе: нужно узнать сумму 100 знаковых целых. Причем тут unsigned?

Где?

Несколько выше на этой странице.

У меня нет на руках С99/С89

На руках нет, но скопипастить вчера фразу из стандарта это тебе не помешало, да? ,)

Эта абстрактная конструкция никак не влияет арифметику чаров.

4.2

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

uint8_t d1[100], d2[100];
.....
uint16_t s = 0;
for(size_t i = 0; i < 100; ++i) s += (d1[i]+d2[i]);

Если бы не было integer promotion, сумма d1[i] и d2[i] никогда не превысила бы 256 (потому что имела бы тип uint8_t). А с integer promotion - запросто может превысить. Итого в s окажется совсем не то значение, которое ожидал бы человек, не подозревающий о promotion.

Да какая же это «прентезия»? В этом сама _суть_ языка.

В таком случае, писать на нем можно только параноикам. А лично тебя допускать до Си нельзя - ты даже 600 страниц стандарта наизусть не помнишь ;) Не говоря уже о понимании тонких нюансов (которые нигде в явном виде нихрена не описаны, блджад).

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

Беда в том, что 99% (да-да, дай Бог, если 1 из 100 внимательно прочитал стандарт) программистов на Си знают синтаксис Си, но понятия не имеют о его семантике. Они пишут на языке, который придуман их воображением (исходя из познаний ассемблера целевой машины, а также исходя из экспериментов с конкретной версией конкретного компилятора), а не на языке, который «будет вести себя универсально на любой машине». Именно в этом состоит претензия. И странно, что ты эту претензию не разделяешь — ведь ты, так же, как и все здесь присутствущие, истинной семантики Си не знаешь.

Сколько я видел старых коммерческих Си/С++ проектов, все они сыпят при компиляции предупреждениями о strict aliasing. Потому, что раньше компиляторы за strict aliasing не цеплялись. И программисты были абсолютно уверены, что их код корректен.

Это «впустую» состоит из POSIX, сокетов, TCP/IP, HTTP, и даже HTML/XML наконец.

На POSIX я бы тоже вылил ушат дерьма, но не в этом топике ;)

> но скопипастить вчера фразу из стандарта это тебе не помешало, да? ,)

Я копипастил из свежевзятого TR3 ;))

> Пример также остается в силе: нужно узнать сумму 100 знаковых целых.

Забыл, что сумму по модулю. Причём по одному единственному модулю. Давай поменяем в твоей задаче модуль - «претензия» всё еще будет в силе?

В таком случае, писать на нем можно только параноикам.

В принципе, да.

А лично тебя допускать до Си нельзя

«Я не волшебник, я только учусь».©

Беда в том, что 99% (да-да, дай Бог, если 1 из 100 внимательно прочитал стандарт) программистов на Си знают синтаксис Си, но понятия не имеют о его семантике.

Ну это не проблемы языка.

Сколько я видел старых коммерческих Си/С++ проектов

Проблемы переносимости.

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

> И странно, что ты эту претензию не разделяешь — ведь ты, так же, как и все здесь присутствущие, истинной семантики Си не знаешь.

Было бы странно, если бы я обвинял используемый мною инструмент в своём же незнании его. )))

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

отрицательный нуль не нужен в целых числах

(а нужен в плавующих — причем лучше бы там были ТРИ нуля ( -0, 0, +0 ); в IEEE 754 обходятся двумя)

> Было бы странно, если бы я обвинял используемый мною инструмент в своём же незнании его.

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

Вот тот пример, что я написал выше: какого хрена компилятор кастит беззнаковый чар к *знаковому* инту? Это приобретает особый цинизм в случает, если оба — и чар, и инт — содержат 32 бита :-)

пример предсказуемого стандарта — уголовный кодекс в нормальном государстве

я не про сроки наказаний — а про то, что можно его вообще не читать, руководствоваться 1 коротким правилом «не делай другим то, что тебе самому очень бы не понравилось» — и не попадать под него

кстати, нынешние цензура в *этой* стране, выдаваемая за наказание за «экстремизм», не вписывается в это простое правило

>> Да какая же это «прентезия»? В этом сама _суть_ языка.

В таком случае, писать на нем можно только параноикам.

Капитан, вы?

> не выполняет роль кроссплаформенного ассемблера.

Пруфы будут? ;)

>> не выполняет роль кроссплаформенного ассемблера.

Пруфы будут? ;)

Ты же сам только что писал: «Проблемы переносимости.» Код может отлично работать на конкретной связке процессор+компилятор+опции_компиляции, но при этом глючить при компиляции под другую платформу. А для написания по-настоящему переносимого кода нужен сферический-в-вакууме маньяк. И такой же сферический-в-вакууме компилятор для целевых патформ, потому что реально доступные компиляторы (благодаря незакрытым багам) стандарту в полной мере не соответствуют. Какие еще тебе нужны «пруфы»?

>> Пример также остается в силе: нужно узнать сумму 100 знаковых целых.

Забыл, что сумму по модулю.

Ох, ну если ты забыл, то могу напомнить: http://www.linux.org.ru/jump-message.jsp?msgid=5163288&cid=5168460

«мне нужно взять сумму 100 слагаемых. Причем я точно знаю, что значение этой суммы лежит между INT_MIN и INT_MAX»

> «мне нужно взять сумму 100 слагаемых. Причем я точно знаю, что значение этой суммы лежит между INT_MIN и INT_MAX»

я точно знаю, что значение этой суммы лежит между INT_MIN и INT_MAX

Какое бесполезное знание. Ты должен знать, что _каждая_ из сумм лежит в диапазоне.

FWIW, любой язык с «обычными» целыми не даст тебе гарантию вычисления такой суммы. Правда, в случае какого-нибудь SML у тебя не будет и UB - будет исключение. Тебе это нужно?

>> В таком случае, писать на нем можно только параноикам.

Капитан, вы?

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

я бы хотел оспорить:

1. продвижения беззнакового типа к знаковому

2. вообще продвижение как таковое — если у целевого проца, допустим, нет байтового оператора сдвига вправо (а есть только двухбайтовый), то надо его эмулировать, а не заставлять разраба писать код под эту редкость; если же разрабу нужен эффективный алгоритм И под этот случай — он напишет его отдельно