В чем причина того, что стандарт C рассматривает константу рекурсивно?

Стандарт C99 говорит в 6.5.16: 2:

Оператор присваивания должен иметь модифицируемое lvalue в качестве своего левого операнда.

и в 6.3.2.1:1:

Модифицируемое lvalue - это lvalue, которое не имеет типа массива, не имеет неполного типа, не имеет типа с константой, и если это структура или объединение, не имеет какого-либо члена (включая рекурсивный любой член) или элемент всех содержащихся агрегатов или объединений) с типом, определенным const.

Теперь давайте рассмотрим не const structс constполем.

typedef struct S_s {
    const int _a;
} S_t;

По умолчанию следующий код является неопределенным поведением (UB):

S_t s1;
S_t s2 = { ._a = 2 };
s1 = s2;

Семантическая проблема в этом заключается в том, что включающий объект ( struct) должен считаться доступным для записи (не только для чтения), судя по объявленному типу объекта ( S_t s1), но не должен считаться доступным для записи в формулировке стандарта (2 предложения на вершине) из-за constполя _a. Стандарт делает неясным для программиста, читающего код, что присвоение на самом деле является UB, потому что невозможно определить это без определения struct S_s ... S_tтипа.

Более того, доступ только для чтения к полю в любом случае обеспечивается только синтаксически. Нет никакого способа, которым некоторые constполя не const structбудут действительно помещены в хранилище только для чтения. Но такая формулировка стандарта запрещает код, который намеренно отбрасывает constспецификатор полей в процедурах доступа к этим полям, например, так ( это хорошая идея, чтобы сопоставить поля структуры в C? ):

(*)

#include <stdlib.h>
#include <stdio.h>

typedef struct S_s {
    const int _a;
} S_t;

S_t *
create_S(void) {
    return calloc(sizeof(S_t), 1);
}

void
destroy_S(S_t *s) {
    free(s);
}

const int
get_S_a(const S_t *s) {
    return s->_a;
}

void
set_S_a(S_t *s, const int a) {
    int *a_p = (int *)&s->_a;
    *a_p = a;
}

int
main(void) {
    S_t s1;
    // s1._a = 5; // Error
    set_S_a(&s1, 5); // OK
    S_t *s2 = create_S();
    // s2->_a = 8; // Error
    set_S_a(s2, 8); // OK

    printf("s1.a == %d\n", get_S_a(&s1));
    printf("s2->a == %d\n", get_S_a(s2));

    destroy_S(s2);
}

Так что, по какой-то причине, для целого, structчтобы быть только для чтения, достаточно объявить этоconst

const S_t s3;

Но для целого, structчтобы быть не только для чтения, недостаточно объявить это без const.

Я думаю, что было бы лучше, либо:

1. Чтобы ограничить создание constнеструктур с constполями, и в таком случае выдать диагностику. Это позволило бы понять, что structсодержащиеся поля только для чтения сами по себе доступны только для чтения.
2. Определить поведение в случае записи в constполе, принадлежащее constнеструктуре, чтобы сделать приведенный выше код (*) совместимым со стандартом.

В противном случае поведение не является последовательным и трудно понять.

Итак, в чем причина того, что C Standard constрекурсивно рассматривает -ness, как он выражается?

Итак, в чем причина того, что C Standard рассматривает константу рекурсивно, как она выражается?

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

И это из-за того, что "=" означает для структуры: это рекурсивное присваивание. Отсюда следует, что в конечном итоге у вас s1._a = <value>происходит "внутри правила набора текста". Если стандарт допускает это для «вложенных» constполей, он добавляет серьезное несоответствие в свое определение системы типов в качестве явного противоречия (может также отбросить constфункцию, поскольку она просто стала бесполезной и ненадежной по своему определению).

Ваше решение (1), насколько я понимаю, излишне заставляет всю структуру быть там, constгде есть одно из ее полей const. Таким образом, s1._b = bбыло бы недопустимо для неконстантного ._bполя в неконстантном поле, s1содержащем a const a.

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

Вы ошибочно полагаете, что единственный эффект - это размещение в ПЗУ, что действительно невозможно при наличии смежных неконстантных полей. В действительности оптимизаторы могут предполагать, что constвыражения не записаны, и оптимизировать на основе этого. Конечно, это предположение не выполняется, когда существуют неконстантные псевдонимы.

Ваше решение (1) нарушает существующий законный и разумный кодекс. Этого не произойдет. Ваше решение (2) в значительной степени удаляет значение для constучастников. Хотя это не нарушит существующий код, похоже, ему не хватает обоснования.