Требуются ли в C++26 реализации «инициализировать» неинициализированные переменные некоторым фиксированному шаблону байтов?

Связанный P2795R5 говорит в разделе «Последствия для производительности и безопасности»:

• Автоматическое хранилище для автоматической переменной всегда полностью инициализируется, что потенциально может повлиять на производительность. P2723R1 подробно описывает затраты. Обратите внимание, что эта стоимость применяется даже тогда, когда создается переменная типа класса, не имеющая заполнения и чей конструктор по умолчанию инициализирует все члены.
• В частности, объединения полностью инициализируются. ...

Он также указывает, что, хотя автоматические локальные переменные могут быть аннотированы [[indeterminate]] для подавления этой инициализации, нет способа избежать этого для каких-либо временных объектов.

Так что похоже ваша интерпретация верна.

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

Изменить - почему я говорю, что не имеет значения, каково магическое значение и даже происходит ли эта инициализация на самом деле?

1. Мотивация состоит в том, чтобы прекратить оценку (т. е. преобразование glvalue в prvalue) неинициализированных автоматических переменных, имеющих неопределенное поведение. Вместо этого это будет ошибочное поведение, которое рекомендуется диагностировать в реализациях.

   • Если реализация не диагностирует ошибочное поведение, результат оценки действителен.

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

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

   • например. вы не можете использовать ни тихий, ни сигнальный NaN для обозначения ошибочных значений, потому что если

     double fine = std::numeric_limits<double>::quiet_NaN;
     double errn;
     
     std::isnan(fine); // not erroneous
     std::isnan(errn); // erroneous behaviour
     

     необходимо обрабатывать оба значения по-разному, оно не может основываться на битовом шаблоне.

   • То же самое тривиально верно и для целочисленных типов, и в любом случае [basic.indet/2] говорит

     За исключением следующих случаев... если в результате оценки получено ошибочное значение, поведение является ошибочным, и результатом оценки является полученное таким образом значение, но не ошибочное.

     где все исключения относятся к «беззнаковому обычному типу символов» и std::byte, поэтому:

     int errn;      // erroneous value
     foo(errn ^ 0); // 1, 2
     foo(errn);     // 3
     

     1. XOR имеет ошибочное поведение, но если его не диагностировать, он должен выдать безошибочное значение с точно такой же битовой комбинацией, что и ошибочный ввод.
     2. вызов foo с неошибочным значением не должен диагностироваться
     3. вызов foo с точно таким же битовым шаблоном может быть диагностирован

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

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

Это зависит от того, что вы подразумеваете под «некоторым фиксированным байтовым шаблоном».

Реализации могут выбирать значения, зависящие от типа переменной, поскольку это статическое свойство программы, не зависящее от ее состояния. В случаях, когда вы заявляете, например. выровненный буфер unsigned char или std::byte и последующее размещение в них новых объектов, обратите внимание, что это первый шаг, получение хранилища, которое записывает в память ошибочные значения; новый шаг размещения будет пустым, если он выполняет тривиальную инициализацию по умолчанию. Но компилятор может выполнить некоторый статический анализ, чтобы увидеть, какой тип памяти вы собираетесь предоставить для использования буфера, и соответствующим образом выбрать ошибочные значения.

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

Обратите внимание, что начальные ошибочные значения не применяются к объектам со статической или потоковой продолжительностью хранения (которые инициализируются нулем) или динамической продолжительностью хранения. Также можно отказаться, используя атрибут [[indeterminate]].