Можно ли избежать проблем с псевдонимами с помощью константных переменных

В моей компании используется сервер обмена сообщениями, который преобразует сообщение в const char*, а затем преобразует его в тип сообщения.

Пока вы имеете в виду, что он выполняет reinterpret_cast (или приведение в стиле C, которое переходит к reinterpret_cast):

MessageJ *j = new MessageJ();

MessageServer(reinterpret_cast<char*>(j)); 
// or PushMessage(reinterpret_cast<char*>(j));

а затем берет этот тот же указатель и повторно интерпретирует его обратно к фактическому базовому типу, тогда этот процесс полностью законен:

MessageServer(char *foo)
{
  if (somehow figure out that foo is actually a MessageJ*)
  {
    MessageJ *bar = reinterpret_cast<MessageJ*>(foo);
    // operate on bar
  }      
}

// or

MessageServer()
{
  char *foo = PopMessage();

  if (somehow figure out that foo is actually a MessageJ*)
  {
    MessageJ *bar = reinterpret_cast<MessageJ*>(foo);
    // operate on bar
  }      
}

Обратите внимание, что я специально исключил константы из ваших примеров, так как их наличие или отсутствие не имеет значения. Вышеприведенное допустимо, когда базовый объект, на который указывает foo, фактически является MessageJ, в противном случае это неопределенное поведение. Повторное приведение к char* и обратно дает исходный типизированный указатель. Действительно, вы можете переинтерпретировать_приведение к указателю любого типа и обратно и получить исходный типизированный указатель. Из этой ссылки:

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

6) Выражение lvalue типа T1 может быть преобразовано в ссылку на другой тип T2. Результатом является значение lvalue или значение x, ссылающееся на тот же объект, что и исходное значение lvalue, но другого типа. Временные объекты не создаются, копии не создаются, конструкторы или функции преобразования не вызываются. Полученная ссылка может быть безопасно доступна только в том случае, если это разрешено правилами псевдонимов типов (см. ниже)...

Псевдоним типа

Когда указатель или ссылка на объект типа T1 переопределяется (или приводится в стиле C) к указателю или ссылке на объект другого типа T2, приведение всегда завершается успешно, но результирующий указатель или ссылка могут быть доступны только в том случае, если оба T1 и T2 являются стандартными типами компоновки, и выполняется одно из следующих условий:

• T2 – динамический тип объекта (возможно, с указанием cv) ...

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

Таким образом, преобразование ваших указателей туда и обратно допустимо, но как насчет потенциальных проблем с псевдонимами?

Возможна ли здесь проблема с псевдонимами, или меня спасает тот факт, что foo только инициализируется и никогда не изменяется?

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

#include <iostream>

int foo(int *x, long *y)  
{
  // foo can assume that x and y do not alias the same memory because they have unrelated types
  // so it is free to reorder the operations on *x and *y as it sees fit
  // and it need not worry that modifying one could affect the other
  *x = -1;
  *y =  0;
  return *x;
}

int main()
{
  long a;
  int  b = foo(reinterpret_cast<int*>(&a), &a);  // violates strict aliasing rule

  // the above call has UB because it both writes and reads a through an unrelated pointer type
  // on return b might be either 0 or -1; a could similarly be arbitrary
  // technically, the program could do anything because it's UB

  std::cout << b << ' ' << a << std::endl;

  return 0;
}

В этом примере, благодаря строгому правилу псевдонимов, компилятор может предположить в foo, что настройка *y не может повлиять на значение *x. Таким образом, он может решить, например, просто вернуть -1 как константу. Без строгого правила алиасинга компилятору пришлось бы предположить, что изменение *y может фактически изменить значение *x. Следовательно, ему придется применить заданный порядок операций и перезагрузить *x после установки *y. В этом примере может показаться достаточно разумным навязать такую ​​паранойю, но в менее тривиальном коде это сильно ограничит переупорядочивание и удаление операций и заставит компилятор гораздо чаще перезагружать значения.

Вот результаты на моей машине, когда я скомпилирую вышеуказанную программу по-другому (Apple LLVM v6.0 для x86_64-apple-darwin14.1.0):

$ g++ -Wall test58.cc
$ ./a.out
0 0
$ g++ -Wall -O3 test58.cc
$ ./a.out
-1 0

В вашем первом примере foo — это const char *, а bar — это const MessageJ * реинтерпретация_преобразования из foo. Далее вы указываете, что базовым типом объекта на самом деле является MessageJ и что чтение через const char * не выполняется. Вместо этого он приводится только к const MessageJ *, из которого затем выполняются только чтения. Поскольку вы не читаете и не пишете через псевдоним const char *, то не может быть проблем с оптимизацией псевдонимов при доступе через ваш второй псевдоним. Это связано с тем, что с базовой памятью не выполняются потенциально конфликтующие операции через ваши псевдонимы несвязанных типов. Однако, даже если вы прочитаете foo, потенциальной проблемы все равно не может быть, поскольку такой доступ разрешен правилами псевдонимов типов (см. пишет происходящее здесь.

Давайте теперь удалим квалификаторы const из вашего примера и предположим, что MessageServer действительно выполняет некоторые операции записи в bar и, кроме того, что функция по какой-то причине также считывает foo (например, - печатает шестнадцатеричный дамп памяти). Обычно здесь может быть проблема с псевдонимами, поскольку чтение и запись происходят через два указателя на одну и ту же память через несвязанные типы. Однако в этом конкретном примере нас спасает тот факт, что foo — это char*, который получает специальную обработку компилятором:

Псевдоним типа

Когда указатель или ссылка на объект типа T1 переопределяется (или приводится в стиле C) к указателю или ссылке на объект другого типа T2, приведение всегда завершается успешно, но результирующий указатель или ссылка могут быть доступны только в том случае, если оба T1 и T2 являются типами стандартной компоновки, и верно одно из следующих утверждений: ...

• T2 – символ или символ без знака

Оптимизация строгого псевдонима, которая разрешена для операций через ссылки (или указатели) несвязанных типов, специально запрещена, когда используется ссылка (или указатель) char. Вместо этого компилятор должен быть параноиком, что операции через ссылку char (или указатель) могут влиять на операции, выполняемые через другие ссылки (или указатели). В модифицированном примере, где операции чтения и записи выполняются как для foo, так и для bar, вы по-прежнему можете иметь определенное поведение, поскольку foo является char*. Таким образом, компилятору не разрешается оптимизировать для изменения порядка или устранения операций над вашими двумя псевдонимами таким образом, чтобы это противоречило последовательному выполнению написанного кода. Точно так же он вынужден параноидально относиться к перезагрузке значений, которые могли быть затронуты операциями через любой из псевдонимов.

Ответ на ваш вопрос заключается в том, что до тех пор, пока ваши функции являются правильными указателями на тип через char* обратно к его исходному типу, ваша функция безопасна, даже если вы будете чередовать чтение (и, возможно, запись, см. предостережение в конце EDIT) через псевдоним char* с чтением и записью через псевдоним базового типа.

Эти два технические справочники (3.10.10) полезны для ответа на ваш вопрос. Эти другие ссылки помогают лучше понять техническую информацию.

====
РЕДАКТИРОВАТЬ: В комментариях ниже zmb возражает, что, хотя char* может законно псевдоним другого типа, обратное неверно, поскольку несколько источников, кажется, говорят в разных формах: что исключение char* из строгого правила псевдонимов является асимметричным, «односторонним» правилом.

Давайте изменим приведенный выше пример кода со строгим псевдонимом и спросим, ​​приведет ли эта новая версия к неопределенному поведению?

#include <iostream>

char foo(char *x, long *y)
{
  // can foo assume that x and y cannot alias the same memory?
  *x = -1;
  *y =  0;
  return *x;
}

int main()
{
  long a;
  char b = foo(reinterpret_cast<char*>(&a), &a);  // explicitly allowed!

  // if this is defined behavior then what must the values of b and a be?

  std::cout << (int) b << ' ' << a << std::endl;

  return 0;
}

Я утверждаю, что это определенное поведение и что и a, и b должны быть равны нулю после вызова foo. Из стандарта C++ (3.10.10):

$ g++ -Wall test59.cc
$ ./a.out
0 0
$ g++ -O3 -Wall test59.cc
$ ./a.out
0 0

Давайте рассмотрим некоторые из на первый взгляд конфликтующий источники:

Обратное неверно. Приведение char* к указателю любого типа, отличного от char*, и разыменование его обычно происходит в соответствии со строгим правилом псевдонимов. Другими словами, приведение указателя одного типа к указателю несвязанного типа через char* не определено.

Выделенный жирным шрифтом бит объясняет, почему эта цитата не относится ни к проблеме, рассматриваемой в моем ответе, ни к примеру, который я только что привел. Как в моем ответе, так и в примере доступ к памяти с псевдонимом осуществляется как через char*, так и через фактический тип самого объекта, поведение которого можно определить.

И C, и C++ позволяют получить доступ к любому типу объекта через char * (или, в частности, через lvalue типа char). Они не позволяют получить доступ к объекту char через произвольный тип. Так что да, правило — это правило «в один конец».

Опять же, жирным шрифтом объясняется, почему это утверждение не относится к моим ответам. В этом и подобных контрпримерах доступ к массиву символов осуществляется через указатель несвязанного типа. Даже в C это UB, потому что массив символов может быть не выровнен, например, в соответствии с требованиями типа с псевдонимом. В C++ это UB, потому что такой доступ не соответствует ни одному из правил псевдонимов типов, поскольку базовый тип объекта на самом деле char.

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

int   value;  
int  *p = &value;  
char *q = reinterpret_cast<char*>(&value);

Оба p и p относятся к одному и тому же адресу, они используют одну и ту же память. Что делает язык, так это предоставляет набор правил, определяющих поведение, которое гарантировано: писать через p читать через q нормально, в противном случае не нормально.

В стандарте и во многих примерах четко указано, что «запись через q, затем чтение через p (или значение)» может быть четко определенным поведением. Что не так совершенно ясно, но то, за что я здесь ратую, так это то, что «записать через p (или значение), затем прочитать через q» всегда хорошо определено. Более того, я утверждаю, что «чтение и запись через p (или значение) могут произвольно чередоваться с чтением и записью в q» с четко определенным поведением.

Теперь есть одно предостережение к предыдущему утверждению, и почему я продолжал разбрасывать слово «может» по всему тексту выше. Если у вас есть ссылка типа T и ссылка char, которые ссылаются на одну и ту же память, то произвольное чередование операций чтения и записи по ссылке T с чтением по ссылке char всегда правильно определено. Например, вы можете сделать это, чтобы повторно распечатать шестнадцатеричный дамп базовой памяти, когда вы изменяете его несколько раз по ссылке T. Стандарт гарантирует, что к этим чередующимся доступам не будут применяться строгие оптимизации псевдонимов, которые в противном случае могут привести к неопределенному поведению.

Но как насчет записи через псевдоним ссылки char? Ну, такие записи могут быть или не быть четко определенными. Если запись по ссылке char нарушает инвариант базового типа T, вы можете получить неопределенное поведение. Если такая запись неправильно изменила значение указателя члена T, вы можете получить неопределенное поведение. Если такая запись изменила значение члена T на значение ловушки, то вы можете получить неопределенное поведение. И так далее. Однако в других случаях запись через ссылку char может быть полностью четко определена. Например, изменение порядка следования байтов uint32_t или uint64_t путем чтения и записи в них через ссылку char с псевдонимом всегда хорошо определено. Таким образом, полностью ли такие записи определены или нет, зависит от особенностей самих операций записи. Несмотря на это, стандарт гарантирует, что его строгая оптимизация псевдонимов не изменит порядок или не устранит такие записи относительно. другие операции с псевдонимом памяти, которые сами по себе могут привести к неопределенному поведению.

Во-первых, приведение указателей не приводит к каким-либо нарушениям алиасинга (хотя может привести к нарушению выравнивания).

Псевдоним относится к процессу чтения или записи объекта через glvalue другого типа, чем объект.

Если объект имеет тип T, и мы читаем/записываем его через X& и Y&, то вопросы таковы:

• Может X псевдоним T?
• Может Y псевдоним T?

Напрямую не имеет значения, может ли X использовать псевдоним Y или наоборот, как вы, кажется, сосредоточились в своем вопросе. Но если X и Y полностью несовместимы, компилятор может сделать вывод, что не существует такого типа T, который может быть совмещен как с X, так и с Y, поэтому он может предположить, что две ссылки относятся к разным объектам.

Итак, чтобы ответить на ваш вопрос, все зависит от того, что делает PopMessage. Если код примерно такой:

const char *PopMessage()
{
     static MessageJ foo = .....;
     return reinterpret_cast<const char *>(&foo);
}

то правильно написать:

const char *ptr = PopMessage();
auto bar = reinterpret_cast<const MessageJ*>(foo);

auto baz = *bar;    // OK, accessing a `MessageJ` via glvalue of type `MessageJ`
auto ch = ptr[4];   // OK, accessing a `MessageJ` via glvalue of type `char`

и так далее. const не имеет к этому никакого отношения. На самом деле, если бы вы не использовали здесь const (или отбросили его), то вы могли бы без проблем писать через bar и ptr.

С другой стороны, если бы PopMessage выглядело примерно так:

const char *PopMessage()
{
    static char buf[200];
    return buf;
}

тогда строка auto baz = *bar; вызовет UB, потому что char не может быть псевдонимом MessageJ. Обратите внимание, что вы можете использовать новое размещение для изменения динамического типа объекта (в этом случае говорят, что char buf[200] перестало существовать, а новый объект, созданный новым размещением, существует и имеет тип T).

Я так понимаю, что вы делаете что-то вроде этого:

enum MType { J,K };
struct MessageX { MType type; };

struct MessageJ {
    MType type{ J };
    int id{ 5 };
    //some other members
};
const char* popMessage() {
    return reinterpret_cast<char*>(new MessageJ());
}
void MessageServer(const char* foo) {
    const MessageX* msgx = reinterpret_cast<const MessageX*>(foo);
    switch (msgx->type) {
        case J: {
            const MessageJ* msgJ = reinterpret_cast<const MessageJ*>(foo);
            std::cout << msgJ->id << std::endl;
        }
    }
}

int main() {
    const char* foo = popMessage();
    MessageServer(foo);
}

Если это правильно, то выражение msgJ->id допустимо (как и любой доступ к foo), так как msgJ имеет правильный динамический тип. msgx->type, с другой стороны, подвергается UB, потому что msgx имеет несвязанный тип. Тот факт, что указатель на MessageJ был приведен к const char* между ними, совершенно не имеет значения.

Как упоминалось другими, вот соответствующая часть стандарта (значение gl является результатом разыменования указателя):

Если программа пытается получить доступ к хранимому значению объекта через значение gl, отличное от одного из следующих типов, поведение не определено:52

1. динамический тип объекта,
2. версия динамического типа объекта с указанием cv,
3. тип, аналогичный (как определено в 4.4) динамическому типу объекта,
4. тип, который является подписанным или беззнаковым типом, соответствующим динамическому типу объекта,
5. тип, который является подписанным или беззнаковым типом, соответствующим cv-квалифицированной версии динамического типа объекта,
6. агрегатный тип или тип объединения, который включает один из вышеупомянутых типов среди своих элементов или нестатических элементов данных (включая, рекурсивно, элемент или нестатический элемент данных подагрегата или содержащегося объединения),
7. тип, который является (возможно, cv-квалифицированным) типом базового класса динамического типа объекта,
8. тип char или unsigned char.

Что касается обсуждения приведения к char* и приведения из char*:
Возможно, вы знаете, что в стандарте не говорится о строгом алиасинге как таковом, он предоставляет только приведенный выше список. Строгий псевдоним — это один из методов анализа, основанный на этом списке, чтобы компиляторы могли определить, какие указатели потенциально могут создавать псевдонимы друг друга. С точки зрения оптимизации не имеет значения, был ли указатель на объект MessageJ приведен к char* или наоборот. Компилятор не может (без дальнейшего анализа) предположить, что char* и MessageX* указывают на разные объекты, и не будет выполнять никаких оптимизаций (например, переупорядочение) на основе этого.

Конечно, это не меняет того факта, что доступ к массиву char через указатель на другой тип по-прежнему будет UB в C++ (я полагаю, в основном из-за проблем с выравниванием), и компилятор может выполнить другие оптимизации, которые могут испортить вам день.

РЕДАКТИРОВАТЬ:

Я спрашиваю: будет ли инициализация const-объекта путем приведения из char* когда-либо оптимизирована ниже, когда этот объект приводится к другому типу объекта, так что я привожу из неинициализированных данных?

Нет, не будет. Анализ псевдонимов влияет не на то, как обрабатывается сам указатель, а на доступ через этот указатель. Компилятор НЕ будет переупорядочивать доступ для записи (сохранение адреса памяти в переменной-указателе) с доступом для чтения (копирование в другую переменную/загрузку адреса для доступа к ячейке памяти) к одной и той же переменной.

При использовании типа (const)char* проблемы с псевдонимом нет, см. последний пункт:

Если программа пытается получить доступ к хранимому значению объекта через значение gl, отличное от одного из следующих типов, поведение не определено:

• динамический тип объекта,
• cv-квалифицированная версия динамического типа объекта,
• тип, аналогичный (как определено в 4.4) динамическому типу объекта,
• тип, который является подписанным или беззнаковым типом, соответствующим динамическому типу объекта,
• тип, который является подписанным или беззнаковым типом, соответствующим cv-квалифицированной версии динамического типа объекта,
• тип агрегата или объединения, который включает один из вышеупомянутых типов среди своих элементов или нестатических элементов данных (включая, рекурсивно, элемент или нестатический элемент данных подагрегата или содержащегося объединения),
• тип, который является (возможно, cv-квалифицированным) типом базового класса динамического типа объекта,
• тип char или unsigned char.