у тебя char переполнился, что ты хотел

При статическом приведении мусора не бывает. char переполнился, туда записалось -128. Потом оно отнялось от INT64_MAX.

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

-128 +127, лалка срочно коммимером в ядро я щетаю

Ну знаковый разряд бы и остался в старшем бите. Зачем столько единичек?

А зачем отнималось?

Почитай про дополнительный код, что ли. У тебя происходит что-то вроде movsx rax, al.

1000000011111111111111111111111111111111111111111111111111111111

0b1111111111111111111111111111111111111111111111111111111110000000

У тебя конвертор неправильный.

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

Да понятно всё, но почему не просто установка единички в старшем разряде?

https://ru.wikipedia.org/wiki/Дополнительный_код_(представление_числа)#.D0.9F...

https://en.wikipedia.org/wiki/Two's_complement#Why_it_works

зачем в лонге единицы появились?

Вот и выросло нувыпонели.

ты так скор набиваешь?

Это всё ясно, неясен кастинг.

Какой кастинг тебе неясен? Из отрицательного числа в дополнительном коде из знаковой переменной в положительное число в беззнаковой?

Да.

А-а, ты хочешь знать, почему -1 не записывается в виде «0b10000001»? Такой вариант есть, но он требует особой логики при складывании чисел со знаком. Использование дополнительного кода позволяет обойтись беззнаковым сумматором, который работает для любых комбинаций.

Кстати, в варианте записи знака старшим битом будут два ноля, +0 и -0. Разные.

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

Так написано

4.7 Integral conversions

 ISO/IEC

(...)

2 If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2 n where n is the number of bits used to represent the unsigned type). [Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ]

(2003й стандарт)

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

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

Таков формат представления знаковых чисел.

Зачем столько единиц? Почему недостаточно одной в старшем разряде?

Возьми байт 00000000 отними от него 1. Какое число получиться? Вот это и есть -1.

Терминологию путаешь. Отнимать можно 100500 разными способами.

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

Ты ответы читаешь? Люди тратят время на ответ по существу, а ты даже не удосуживаешь себя пониманием прочитанного.

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

Мда. 10000001 это совсем не число -1.

Ну и для полного осознания. -1 это 11111111

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

Ладно, зачот.

Всегда было 1000000.

Я читаю, но не врубаюсь.

а ты даже не удосуживаешь себя пониманием прочитанного

Он просто троллит.

Попробуй это число распечатать как знаковый char.

На твоей платформе char это знаковый тип. Поэтому в p хранится значение "-128", а не «128». При конверсии к unsigned значению к данному значению прибавляется 2^64 (потому что так написано в стандарте) и результат ты видишь (2^64 + (-128)). Если бы char у тебя был беззнаковый (на некоторых платформах такое бывает), у тебя бы получилось то, что ты ожидаешь.

Спасибо.

Всегда было 1000000

Расходимся

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

Почему недостаточно одной в старшем разряде?

По кочану!