Всегда ли C99 требует, чтобы тип int64_t был доступен?

Не уверен насчет C99, но int64_t определенно необязателен в C11, за исключением случаев, когда это не так. Подробности см. в разделе 7.20.1.1 спецификации C11.

@ user3386109: Могу я вас попросить ссылку? Кроме того, ваша формулировка довольно загадочна.

Извините, у меня нет ссылки. Но проект спецификации C11 находится в свободном доступе в Интернете, и его можно найти, выполнив поиск N1570

В любом случае ответ "нет". Вы не можете рассчитывать на существующие типы.

Возможный дубликат Общие сведения о целочисленных типах фиксированной ширины

@phuclv: Все это просто не то, о чем я просил.

Определенно да. Все они говорят, что целые числа фиксированной ширины не требуются в системах, которые их не поддерживают. Требуется только вариант least

Использование слова «вероятно» не звучит как однозначный ответ.

Юу мог бы так же легко сослаться на черновик C99 и быть категоричным. open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

C не требует, чтобы long long был 64-битным. LLONG_MIN разрешено быть -0x7fffffffffffffff, что делает его почти на 100 зептобит меньше 64-битного, если реализация делает такой плохой выбор (и, для практических целей, 63-битный).

@R.. Согласитесь, что «C не требует, чтобы long long был 64-битным», поэтому в ответе есть «long long, который находится в наименее 64-битном». Может быть шире. Он может иметь такой узкий диапазон, как [-0x7fff-ffff-ffff-ffff ... +0x7fff-ffff-ffff-ffff]

Он даже не требует, чтобы он был «не менее 64 бит». для этого требуется, чтобы он был не менее 63,999999999999999999921... бит. Извините, мой первый комментарий был неправильно сформулирован и в нем отсутствовала фраза «по крайней мере», но дело в том, что «по крайней мере» ложно из-за обратных положений, разрешающих реализации с дополнением до единицы, знаком/величиной и «недостаточным дополнением до двух».

@R.. Поскольку дробных бит не существует, это то же самое, что «не менее 64 бит».

@Barmar: Нет, вам нужно округлить в меньшую сторону, если вы хотите подсчитывать только целые биты, и в этом случае он фактически 63-битный (т. Е. Самый большой интервал степени двойки, который полностью представлен в диапазоне, составляет 2 ^ 63 в длину, не 2^64). Один из способов думать об этом состоит в том, что один бит потенциально «не полностью пригоден для использования».

@R.. Типы со знаком ограничены общим два дополнения. Редкое дополнительное кодирование знак и величина и дополнение также требует минимального 64-битного кодирования. Конечно, мы разделяем волосы / биты. ;-)

Обратите внимание, что следующая версия стандарта C исправит это, предписав полное дополнение до двух для всех целочисленных типов. Мы должны поблагодарить за это JF Bastien из SO! :-)

@R.. Если вам требуется не менее 63,9999... бит, и вы округляете в меньшую сторону, у вас будет меньше битов, и вы не сможете закодировать весь диапазон.

@R.. Интересные новости о следующей версии C. Есть ожидаемый год?

Я думаю, что он будет больше сосредоточен на очень важных вопросах, таких как триграфы и так далее. Любая попытка модернизации будет противодействовать IBM (как всегда), поскольку они создали 60 лет назад странные архитектуры и хотят, чтобы на них можно было реализовать стандарт C.

@Barmar: Дело в том, что вы не можете представить полный 64-битный диапазон в такой реализации, поэтому, если вы хотите рассматривать long long как имеющий диапазон степени двойки, вы должны рассматривать его только как 63-битный. Конечно, вы можете рассматривать его как имеющий полный почти 64-битный диапазон, но это не 64-битный диапазон, и неправильно описывать его как таковой.

@chux: Кажется, я где-то видел оценку, но не помню, где. Тем не менее, я время от времени связывался с jfbastien через Twitter и другие каналы по поводу предложения и его принятия.

@R.. Я хочу сказать, сколько бит вам нужно для представления требуемого диапазона. Представление знак/величина не может представлять тот же диапазон, что и 64-битное дополнение до двух, но для представления этого диапазона все равно требуется 64 бита (63 бита величины, 1 бит знака).

@Barmar: Обычно при использовании типа вас волнует диапазон значений, которые он может представлять, а не (или, по крайней мере, больше) объем памяти, который ему требуется. Если вы говорите о хранении, вы также должны учитывать биты заполнения.

@Р.. Конечно. Но вы были тем, кто сказал, что «требуется не менее 63,9999999999999999999921... бит», что, похоже, говорит об объеме памяти.

@Barmar: Скорее речь идет о пространстве возможных значений. Дробные биты имеют смысл, когда речь идет об энтропии/возможностях.

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

Также есть машины класса DSP с CHAR_BIT из 16. У них есть проблемы с int8_t, но не с другими типами.

Обратите внимание, что хотя int_least64_t обязан существовать, его диапазон не обязательно должен быть как минимум таким же большим, как int64_t, если бы он существовал. int_least64_t разрешено снижаться только до -2 ^ 63 + 1, а не до -2 ^ 63. Это будет исправлено в следующей редакции стандарта C. См. 7.20.2.2 Ограничения целочисленных типов минимальной ширины.

@JonathanLeffler никто не пишет для них переносимый код. Если кто-то попытается использовать на них uint8_t, следует найти более легкую работу.

Итак, может ли у вас быть компилятор, совместимый с C99, который не предоставляет int64_t? Я имею в виду, может ли, скажем, long long иметь размер, не равный степени двойки, или 128 бит, а int64_t отсутствовать?

Да, @einpoklum, в принципе можно. Как я уже сказал, «соответствующая реализация не обязана предоставлять какой-либо тип, который точно соответствует характеристикам int64_t, а если это не так, то она не должна (действительно, не должна [...]) предоставлять тип int64_t ". Однако на практике я не знаю ни одной существующей реализации, соответствующей C99 или C11, которая не обеспечивает int64_t.