Краткое примечание для читателей, не знающих о C3: это язык системного программирования, продолжающий традиции C. В статье приведена специфика C3, но все плюсы и минусы применимы к любому языку, в котором нужно выбирать типы для размеров и длин.

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

Баги беззнаковых типов

С самого начала проекта в C3 использовались беззнаковые размеры. И хотя имя беззнакового типа со временем менялось с «usize» на «usz» (после объединения с типом uptrdiff), оно всё равно оставалось используемым по умолчанию.

Однако у беззнаковых типов есть хорошо известные изъяны; вот самый известный из них:

for (uint x = 10; x >= 0; x--) // Бесконечный цикл!
{ ... }

На самом деле, этот баг так легко вызвать, что C3 вне пределов макросов явным образом отклоняет x >= 0 для беззнаковых типов.

Ещё один классический баг C:

uint a = 0;
int b = -1;

if (a > b) { ... }

В C оба значения будут превращены в беззнаковые, из-за чего b становится огромным беззнаковым значением, поэтому сравнение выполнится неверно. По этой причине в C3 реализованы безопасные сравнения знаковых/беззнаковых типов, которые не преобразуют обе части, обеспечивая при этом безопасность.

Разумеется, в C допускаются косвенные преобразования между беззнаковыми и знаковыми типами. Хоть это и становится источником багов, я посчитал, что благодаря добавлению мер защиты это по большей мере можно оставить в C3.

Можно подумать, что представленные выше баги — это никак не связанные друг с другом особенности языка. Непрекращающийся цикл, поломанное сравнение, преобразования, с которыми нужно соблюдать аккуратность... всё это произрастает из одного раннего решения: по умолчанию для размеров должны использоваться беззнаковые типы. Основная часть моего поста посвящена этому решению.

Уместный вопрос

Можно вполне резонно задать вопрос: «Но почему бы просто не сделать обязательным явное преобразование между знаковым и беззнаковым?».

Как оказалось, причина заключается в беззнаковых размерах.

Если размеры беззнаковые, как в C, C++, Rust и Zig, то из этого следует, что всё, что касается индексации в данных, должно быть беззнаковым или требовать преобразований типов. В случае свободной семантики C на эту проблему в основном закрывают глаза, но в Rust из-за этого при работе с размерами пришлось бы регулярно выполнять преобразования туда и обратно.

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

Первое решение проще определить, но его недостаток в том, что фактически оно «заглушает предупреждения». Допустим, код изначально должен был преобразовывать тип из u16 в u32, но позже тип переменной сменился с u16 на u64, и преобразование теперь незаметно обрезает данные. Получается, преобразования типов превратились в умалчивание всех предупреждений.

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

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

C3 пошёл по второму пути: преобразования должны что-то значить, но почему он разрешает беззнаковые <-> знаковые? Это ведь небезопасно?

Оказывается, что если использовать только сложение, вычитание и умножение, это по большей мере достаточно безопасно, если целочисленные значения со знаком представлены в дополнительном коде. А учитывая то, что преобразования должны происходить часто (помните: размеры беззнаковые!), естественно было сделать их косвенными.

Гладко было на бумаге

В основном современная семантика преобразований оставалась в C3 неизменной с 2021 года и в течение пяти лет работала достаточно хорошо, не вызывая никакой серьёзной нежелательной семантики; но затем невинный вопрос о (foo + a) % 2 перевернул все эти допущения.

Чтобы избавиться от возможностей выстрелов в ногу, в C3 было решено, что «int + uint» преобразуется в «int», а не в беззнаковый тип. Благодаря этому гораздо большее количество случаев получало знак, что в большинстве случаев было правильным решением. Но что делать, если мы выполняем (foo + a) % 2, и foo здесь оказывается больше INT_MAX? Внезапно мы получаем необъяснимые результаты! Правильным ответом оказывается (foo + a) % 2U.

Эта проблема была неприемлемой. Не потому, что её сложно устранить, а потому, что она оказалась столь неожиданной. Почти во всех случаях можно было игнорировать то, происходило ли косвенное преобразование в знаковый тип, всё просто работало. Но в случае / и % это решение ломалось. А поскольку оно «просто работало» во всех остальных случаях, было довольно непонятно, окажется ли подвыражение знаковым или беззнаковым. Удобство превратило эту маленькую проблему в серьёзную.

Первым делом мы решили это пропатчить: просто выдавать ошибку при выполнении «знаковый / беззнаковый» и «беззнаковый % знаковый», но в тени таились новые проблемы.

Сложный возврат

Если вы пишете кольцевой буфер, то как проверить, что вычисляемые смещения циклически переполняются и возвращаются в начало?

Наивное решение было бы таким:

index = (start + offset) % length;

Оно работает, пока offset положительное. Но что насчёт отрицательных значений? Вот популярное простое решение:

index = ((start + offset) % length + length) % length;

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

(Примечание: если бы % возвращал остаток по модулю, а не от деления, то наивное решение сработало бы.)

Помните, с чего мы начали тему о беззнаковых размерах? Если использовать их в первую очередь, то это скорее всего приведёт к применению всех беззнаковых, а код начнёт выглядеть так:

index = ((start - offset_back) % length + length) % length;

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

Корректный код для беззнакового типа должен выглядеть примерно так:

index = (start + length - (offset_back % length)) % length;

Какие бы правила мы ни применили к преобразованиям беззнаковых и беззнаковых в знаковые, компилятор просто не сможет сообщить нам, когда первый пример «offset_back» окажется поломанным для беззнаковых.

Поэтому давайте немного вернёмся назад.

Беззнаковый размер

Похоже, решить проблему беззнаковых сложно; возможно мы принимаем какое-то ошибочное допущение?

Обратимся к истории: изначально в C по большей мере использовались знаковые целые, основанные на типе int. Всё поменялось, когда тип sizeof был стандартизирован, как беззнаковый size_t.

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

Но это не значит, что проблем не было. На самом деле, проблемы были столь существенными, что 90-х создатели Java решили полностью отказаться от беззнаковых типов. Возможно, их реакция была слишком резкой, но зато она позволила достичь цели: устранить большое множество распространённых багов, связанных с беззнаковыми типами.

Go должен заставить нас призадуматься: это низкоуровневый язык, созданный как реакция на проблемы C++ людьми, точно знавшими, как приходится расплачиваться за беззнаковые размеры, поэтому они выбрали размеры со знаком.

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

Именно поэтому мы встречаем проблемы в случаях наподобие %.

Но что насчёт диапазона? Хоть мы действительно можем удвоить диапазон, код в диапазоне выше максимума знакового int на удивление часто оказывается полон багов. Любой код, выполняющий в этом диапазоне что-то наподобие (2U * index) / 2U, ожидает довольно неприятный сюрприз. Но на самом деле, всё ещё хуже: переполнение в случае значений со знаком обычно приводит к получению недопустимого отрицательного числа, однако беззнаковое переполнение часто создаёт вполне правдоподобное, но ошибочное значение. Не говоря уже о том, что на современных 64-битных машинах у нас скорее закончится память, чем мы полностью израсходуем весь диапазон 64-битных целых чисел со знаком.

Допустим, но не ценно ли то, что мы изначально находимся в нужном диапазоне? Судя по работе с фреймворками верификации, ответ здесь отрицательный, поскольку беззнаковые типы кодируют только поведение по модулю и фактические диапазоны значений. Можно возразить, что переполнение беззнаковых типов можно сделать ошибкой (именно так, например, поступает Rust), но тогда теряются полезные свойства беззнаковой арифметики: выражение (a + b) - c равно a + (b - c) при циклическом переполнении беззнаковой арифметики, но не равно, в случае отсутствия такого переполнения. Это само по себе ловушка.

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

Знаковые типы по умолчанию

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

При внесении этого изменения я начал также избавляться от несвязанных с этим случаев использования uint и ulong, обнаруживая код, который казался подозрительным или откровенно неверным. Кроме того, когда повсюду начали использоваться только int и знаковые размеры, код стал проще. И на этом этапе я осознал, что затраты на использование беззнаковых типов заключались в моих внутренних усилиях: если поработаешь какое-то время на C или C++, то у тебя появляется привычка искать возможные проблемы, связанные с беззнаковыми типами, или использовать менее очевидные паттерны, чтобы они точно работали и для знаковых, для беззнаковых переменных.

Меня неприятно поразило то, что на это изменение потребовалось так много времени; это стало доказательством того, насколько глубоко въелась в меня эта привычка. Я просто считал, что беззнаковые размеры — это нужное решение, и что проблема заключалась лишь в повышении эргономики и устранении максимального количества тонких моментов. И всё это несмотря на то, что Go и Java показали нам путь работы со знаковыми размерами.

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

Примечания об изменениях в C3

Перед реализацией этого изменения его обсуждали на Discord-сервере C3, где оно получило громкое название «iszmageddon» в честь типа isz (приблизительно соответствующего ssize_t), который должен был стать типом для размеров по умолчанию.

Чтобы более чётко заявить о знаковом размере, он был переименован в «sz», благодаря чему в версии 0.8.0 появилась асимметричная пара sz/usz. Так легко запомнить, какой из них предпочтительнее использовать. Поэтому изменение переименовали в «szmageddon».

Изначально косвенное преобразование знаковые <-> беззнаковые в основном оставили без изменений, но позже от него полностью отказались.