Как оценивается оператор sizeof

Семантика sizeof()согласно (черновому) стандарту C11:

Оператор sizeof возвращает размер (в байтах) своего операнда, который может быть выражением или именем типа в скобках. Размер определяется типом операнда. Результат — целое число. Если тип операнда является типом массива переменной длины, вычисляется операнд; в противном случае операнд не оценивается и результатом является целочисленная константа.

Примечание: «Если тип операнда является типом массива переменной длины, операнд оценивается». Это означает, что размер VLA вычисляется во время выполнения.

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

Тип возвращаемого значения — size_t. Точка:

Значение результата обоих операторов (sizeof() и _Alignof()) определяется реализацией, а его тип (целочисленный тип без знака) — size_t, определенный в <stddef.h> (и других заголовках).

Обратите внимание, что тип size_t. Не используйте ни unsigned long, ни unsigned long long, ни что-либо еще. Всегда используйте size_t.

1. Мои предыдущие знания предполагали, что это оператор времени компиляции, который я никогда не подвергал сомнению, потому что я никогда не злоупотреблял sizeof слишком сильно…

C 2018 6.5.3.4 2 определяет поведение sizeof и говорит:

… Если тип операнда является типом массива переменной длины, вычисляется операнд; в противном случае операнд не оценивается и результатом является целочисленная константа.

В вашем примере с sizeof(int[size]) тип int[size] является типом массива переменной длины, поэтому операнд оценивается¹, эффективно вычисляя размер во время выполнения программы.

В вашем примере с sizeof(*p) тип *p не является типом массива переменной длины, поэтому операнд не оценивается. Тот факт, что p может указывать на объект автоматической продолжительности хранения, который создается во время выполнения программы, не имеет значения; тип *p известен во время компиляции, поэтому *p не оценивается, а результатом sizeof является целочисленная константа.

2. Возвращает ли sizeof значение типа int, это size_t (ULL на моей платформе) или оно определяется реализацией.

C 2018 6.5.3.4 5 говорит: «Значение результата обоих операторов [sizeof и _Alignof] определяется реализацией, а его тип (целочисленный тип без знака) — size_t, определенный в <stddef.h> (и других заголовках) ».

3. В этой статье говорится, что «Операнд для sizeof не может быть преобразованием типа», что неверно. Приведение типов имеет тот же приоритет, что и оператор sizeof, то есть в ситуации, когда используются оба, они просто оцениваются справа налево. sizeof(int) * p, вероятно, не работает, потому что если операнд является типом в фигурных скобках, он обрабатывается первым, но sizeof((int)*p) работает нормально.

Статья означает, что операнд не может быть непосредственно приведенным выражением (C 2018 6.5.4) в форме ( type-name ) cast-expression из-за того, как устроена формальная грамматика C. Формально операнд выражения для sizeof является унарным-выражением (6.5.3) в грамматике, а унарное-выражение может через цепочку грамматических производств быть приведенным-выражением внутри круглых скобок.

Сноска

¹ Мы часто думаем об имени типа (спецификации типа, например int [size]) как о пассивном объявлении, а не об исполняемой инструкции или выражении, но C 2018 6.8 4 говорит нам: «Существует также неявное полное выражение, в котором вычисляются выражения непостоянного размера для изменяемого типа...»

Вы немного переоцениваете вещи.

Да, когда операндом sizeof является выражение массива переменной длины, его необходимо оценивать во время выполнения, иначе это операция времени компиляции, и операнд не оценивается.

printf("%i\n", sizeof(*p));

Я не помню точный код, который создает U/B, но здесь *p — это фактическое выражение (унарное разыменование RTL).

Не имеет значения — выражение *p не вычисляется как часть операции sizeof. Имеет значение только тип *p, который известен при переводе. Это совершенно верная идиома для динамического выделения памяти:

size_t size = some_value();
int *p = malloc( sizeof *p * size );

Предположительно, означает ли это, что sizeof(c+c) — это способ принудительной оценки времени компиляции с помощью выражения или он будет оптимизирован компилятором?

Опять же, выражение c+c не будет оцениваться — важен только тип.

Возвращает ли sizeof значение типа int, это size_t (ULL на моей платформе) или оно определяется реализацией.

size_t. Это прямо указано в определении языка:

6.5.3.4 Операторы sizeof и _Alignof
...
5 Значение результата обоих операторов определяется реализацией, а его тип ( целочисленный тип без знака) — это size_t, определенный в <stddef.h> (и других заголовках).

В этой статье говорится, что «Операнд для sizeof не может быть преобразованием типа», что неверно. Приведение типов имеет тот же приоритет, что и оператор sizeof, то есть в ситуации, когда используются оба, они просто оцениваются справа налево. sizeof(int) * p, вероятно, не работает, потому что если операнд является типом в фигурных скобках, он обрабатывается первым, но sizeof((int)*p) работает нормально.

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

unary-expression:
    ...
    sizeofunary-expressionsizeof ( type-name)

и синтаксис для приведенного выражения

cast-expression:
    unary-expression(type-name)cast-expression

Если написать выражение типа

sizeof (int) *p;

это не будет проанализировано как

sizeof ((int) *p);

Вместо этого он будет проанализирован как

(sizeof (int)) *p;

и интерпретируется как мультипликативное выражение:

multiplicative-expression*cast-expression

IOW, компилятор подумает, что вы пытаетесь умножить результат sizeof (int) на значение p (что должно привести к диагностике). Если вы заключаете выражение приведения в круглые скобки, то оно анализируется правильно.

Приведение типов имеет тот же приоритет, что и оператор sizeof.

Это неправильно. Унарные выражения (включая выражения sizeof) имеют более высокий приоритет, чем выражения приведения. Вот почему sizeof (int) *p анализируется как (sizeof (int)) *p.

Вот попытка предоставить полное руководство по оператору sizeof и его многочисленным особенностям. Предупреждение: этот пост может содержать сильную «языковую юриспруденцию».

Формальный синтаксис и допустимые формы

sizeof является ключевым словом в C, а синтаксис определен в C17 6.5.3 как:

sizeof унарное выражение
sizeof( название типа )

Это означает, что есть два возможных способа его использования: sizeof op или sizeof(op). В первом случае операнд должен быть выражением (например, sizeof my_variable), а во втором — типом (например, sizeof(int)).

Когда мы используем sizeof, мы почти всегда используем скобки. Всегда использовать скобки считается хорошей практикой (и, как известно, у Линуса Торвальдса однажды была одна из его обычных детских истерик по этому поводу). Но какую форму sizeof мы используем, зависит от того, передаем ли мы выражение или тип. Таким образом, даже когда мы используем круглые скобки вокруг выражения, мы на самом деле используем не вторую версию, а первую. Пример:

int x;
printf("%zu\n", sizeof(x));

В этом случае мы передаем выражение в sizeof. Выражение — это (x), а скобка — это обычная скобка («первичное выражение»), которую мы можем использовать вокруг любого выражения в C — в данном случае она не принадлежит оператору sizeof.

«Операнд sizeof не может быть типизирован» - приоритет и ассоциативность или ...?

Следуя приведенному выше объяснению, всякий раз, когда мы пишем sizeof (int) * p, это интерпретируется как вторая форма с именем типа. Почему?

Почему вообще не очень очевидно, это на самом деле чертовски тонко. Легко быть обманутым «таблицами приоритета операторов», такими как та, которую вы связываете. В нем говорится, что оператор приведения типа sizeof является унарным оператором с ассоциативностью справа налево. Но на самом деле это не так, если копаться в грязных деталях грамматики C.

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

унарное выражение:

постфиксное выражение
++ унарное выражение
-- унарное выражение
унарное операторное выражение приведения
sizeof унарное выражение
sizeof( название типа )
_Alignof( название типа )

унарный оператор: один из
& * + - ˜ !

В переводе со стандартного на английский эта грамматическая каша читается примерно так:

«Вот группа унарных выражений. Это префиксные операторы ++ и --, или один из унарных операторов (перечисленных отдельно), или sizeof в двух разных формах, или _Alignof. Они могут следовать за постфиксным выражением, что означает, что любой постфиксное выражение (или группы операторов еще выше по синтаксической цепочке) имеет более высокий приоритет, чем унарные операторы. За ними может следовать выражение приведения, которое, таким образом, имеет более низкий приоритет, чем унарные операторы».

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

Так или иначе, оператор sizeof(имя типа) является унарным выражением и имеет приоритет в грамматике над оператором приведения. И именно поэтому компилятор будет рассматривать это не как два оператора sizeof и (cast), а как оператор sizeof(type), за которым следует оператор двоичного умножения.

Итак, sizeof (int) * p превращается в эквивалент (sizeof(int)) * p, sizeof с двоичным умножением, что, вероятно, является ерундой, и, возможно, фактическое намерение здесь состояло в том, чтобы разыменовать указатель p, привести и затем получить размер.

Однако мы могли бы написать что-то вроде sizeof ((int)*p)), и тогда порядок синтаксического анализа будет таким: круглые скобки, затем (из-за ассоциативности унарного оператора справа налево) разыменование, затем приведение, затем sizeof.

Какой тип возвращает sizeof?

Он возвращает особый большой целочисленный тип без знака size_t (C17 6.5.3.4/5), который обычно считается «достаточно большим», чтобы содержать самый большой объект, разрешенный в системе. Этот тип обычно используется всякий раз, когда мы хотим получить размер чего-либо, например, при переборе массива.

Например, вы можете увидеть некоторый код на SO в форме for(size_t i=0; i<n; i++) при переборе массива, поскольку это наиболее правильный тип «достаточно большой», чтобы содержать размер массива. (int может быть слишком маленьким, и, кроме того, он тоже подписан, и у нас не может быть отрицательных размеров.)

size_t находится в stddef.h, который, в свою очередь, включен во многие другие стандартные заголовки, такие как stdio.h. Он может содержать значения до SIZE_MAX, определенные в stdint.h.

size_t печатается с printf с помощью спецификатора преобразования %zu, отсюда и мой предыдущий пример printf("%zu\n", sizeof(x));.

Время компиляции или время выполнения?

sizeof обычно является оператором времени компиляции, что означает, что операнд не оценивается. За одним исключением, это массивы переменной длины (VLA), размер которых просто неизвестен во время компиляции.

С17 6.5.3.4/2:

Оператор sizeof возвращает размер (в байтах) своего операнда, который может быть выражением или имя типа в скобках. Размер определяется типом операнда. Результат является целым числом. Если тип операнда является типом массива переменной длины, вычисляется операнд; в противном случае операнд не оценивается и результатом является целочисленная константа.

Большую часть времени это не имеет значения. Однако мы можем состряпать какой-нибудь искусственный пример вроде этого:

#include <stdio.h>

int main (void)
{
  int size;
  scanf("%d",&size); // enter 2
  int arr[5][size];

  printf("%zu ", sizeof(size++)); // size++ not executed
  printf("%d ", size); // print 2

  printf("%zu ", sizeof(arr[size++])); // size++ is executed
  printf("%d ", size);
}

Когда я пробую это и ввожу 2, он печатает 4 2 8 3:

• 4, потому что это размер int в этой системе.
• 2, потому что операнд size++ не был выполнен/оценен.
• 8, потому что 2 * sizeof(int) равно 8.
• 3, потому что операнд arr[size++] был выполнен/оценен, так как arr[n] приводит к операнду VLA.

Это поведение того, какой операнд оценивается или нет, четко определено и гарантировано.

Отсюда популярный трюк int* ptr = malloc(n * sizeof *ptr);. В случае, если *ptr будет оцениваться, это неинициализированный указатель, который мы определенно не можем разыменовать, и это было бы неопределенным поведением. Но поскольку он гарантированно не будет оценен, трюк безопасен.

Исключение из "распада массива"

sizeof — один из немногих операндов, который является исключением из правила «затухания массива»:

С17 6.3.2.1/3

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

sizeof используется в определении байта в C

Размер байта в C определяется согласно C17 3.6.

3.6
байт
адресная единица хранения данных, достаточно большая, чтобы вместить любой элемент базового набора символов среды выполнения

а затем 6.5.3.4/4:

Когда sizeof применяется к операнду, имеющему тип char, unsigned char или signed char (или его уточненную версию), результатом будет 1.

По этой причине не имеет особого смысла писать такие вещи, как malloc(n * sizeof(char), потому что sizeof(char) по определению гарантировано всегда равно 1.

(Однако количество битов в char не обязательно равно 8.)