Тип целочисленных литералов не int по умолчанию?

Я просто ответил на этот вопрос, в котором спрашивали, почему итерация до 10 миллиардов в цикле for занимает гораздо больше времени (OP фактически прервал его через 10 минут), чем итерация до 1 миллиарда:

for (i = 0; i < 10000000000; i++)

Теперь мой и многие другие очевидный ответ заключался в том, что это связано с тем, что переменная итерации была 32-разрядной (которая никогда не достигает 10 миллиардов), а цикл получает бесконечный цикл.

Но хотя я понял эту проблему, я все еще задаюсь вопросом, что действительно происходит внутри компилятора?

Поскольку литерал не был добавлен с помощью L, он должен ИМХО иметь тип int, а также 32-разрядный. Поэтому из-за переполнения в пределах диапазона должен быть нормальный int. Чтобы действительно понять, что из int не может быть достигнуто, компилятор должен знать, что он составляет 10 миллиардов, и поэтому рассматривайте его как более чем 32-битную константу.

Будет ли такой литерал автоматически повышаться до подходящего (или, по крайней мере, определенного для реализации) диапазона (по крайней мере, 64-битного в этом случае), даже если он не добавлен L и является ли это стандартным поведением? Или что-то другое происходит за кулисами, например UB из-за переполнения (на самом деле происходит переполнение целого числа UB)? Некоторые цитаты из Стандарта могут быть приятными, если они есть.

Хотя исходный вопрос был C, я также ценю ответы на С++, если они существуют.

Ответ 1

Что касается С++:

С++ 11, [lex.icon] ¶2

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

И таблица 6 для литералов без суффиксов и десятичных констант дает:

int
long int
long long int

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

Итак, ясно, что в этом случае константа была интерпретирована как long int (или long long int, если long int было слишком 32 бит).

Обратите внимание, что "слишком большие литералы" должны приводить к ошибке компиляции:

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

(ibidem, ¶3)

который быстро отображается в этом примере, что напоминает нам, что ideone.com использует 32-битные компиляторы.

Теперь я увидел, что вопрос о C... ну, это более или менее то же самое:

C99, §6.4.4.1

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

который аналогичен стандарту С++.

Добавление: как C99, так и С++ 11 разрешают также литералы иметь "расширенные целые типы" (т.е. другие целые типы, специфичные для реализации), если все остальное не выполняется. (С++ 11, [lex.icon] ¶3; C99, §6.4.4.1 ¶5 после таблицы)

Ответ 2

Из моего проекта стандарта C, помеченного как ИСО/МЭК 9899: Проект Комитета TC2 - 6 мая 2005 года, правила очень похожи на правила С++, найденные Маттео:

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

Suffix      Decimal Constant          Octal or Hexadecimal Constant
-------------------------------------------------------------------
none        int                       int
            long int                  unsigned int
            long long int             long int
                                      unsigned long int
                                      long long int
                                      unsigned long long int

u or U      unsigned int              unsigned int
            unsigned long int         unsigned long int
            unsigned long long int    unsigned long long int

l or L      long int                  long int
            long long int             unsigned long int
                                      long long int
                                      unsigned long long int
Both u or U unsigned long int         unsigned long int
and l or L  unsigned long long int    unsigned long long int

ll or LL    long long int             long long int
                                      unsigned long long int

Both u or U unsigned long long int    unsigned long long int
and ll or LL

Ответ 3

Я все еще удивляюсь, что действительно происходит внутри компилятора

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

10000000000

400054f:
mov    -0x4(%rbp),%eax
mov    %eax,-0x8(%rbp)
addl   $0x1,-0x4(%rbp)
jmp    40054f <main+0xb>

поэтому он просто скомпилировал его в бесконечный цикл, если заменить 10000000000 на 10000:

....
test   %al,%al
jne    400551