Почему указатели на функции и указатели данных несовместимы в C / C ++?

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

Архитектура не обязана хранить код и данные в одной и той же памяти. В гарвардской архитектуре код и данные хранятся в совершенно другой памяти. Большинство архитектур - это архитектуры фон Неймана с кодом и данными в одной и той же памяти, но C не ограничивается только определенными типами архитектур, если это вообще возможно.

Некоторые компьютеры имеют (имели) отдельные адресные пространства для кода и данных. На таком оборудовании просто не работает.

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

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

Обоснование C99 гласит:

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

Использование void*(«указатель на void») в качестве универсального типа указателя объекта является изобретением Комитета C89. Принятие этого типа было стимулировано желанием указать аргументы прототипа функции, которые либо незаметно преобразуют произвольные указатели (как в fread), либо жалуются, если тип аргумента не совпадает в точности (как в strcmp). Ничего не сказано об указателях на функции, которые могут быть несоизмеримы с указателями на объекты и / или целыми числами.

Примечание. В последнем абзаце ничего не говорится об указателях на функции . Они могут отличаться от других указателей, и комитет это знает.

Для тех, кто помнит MS-DOS, Windows 3.1 и старше, ответ довольно прост. Все они используются для поддержки нескольких различных моделей памяти с различными комбинациями характеристик для кода и указателей данных.

Так, например, для модели Compact (небольшой код, большие данные):

sizeof(void *) > sizeof(void(*)())

и наоборот, в модели Medium (большой код, небольшие данные):

sizeof(void *) < sizeof(void(*)())

В этом случае у вас не было отдельного хранилища для кода и даты, но вы все равно не могли конвертировать между двумя указателями (за исключением использования нестандартных модификаторов __near и __far).

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

Предполагается, что указатели на void могут содержать указатель на любые данные, но не обязательно указатель на функцию. В некоторых системах требования к указателям на функции отличаются от требований к указателям на данные (например, существуют DSP с разной адресацией для данных и кода, в средней модели в MS-DOS используются 32-разрядные указатели для кода, но только 16-разрядные указатели для данных) ,

Помимо того, что здесь уже сказано, интересно посмотреть на POSIX dlsym():

Стандарт ISO C не требует, чтобы указатели на функции могли быть преобразованы туда и обратно к указателям на данные. Действительно, стандарт ISO C не требует, чтобы объект типа void * мог содержать указатель на функцию. Однако реализации, поддерживающие расширение XSI, действительно требуют, чтобы объект типа void * мог содержать указатель на функцию. Однако результат преобразования указателя на функцию в указатель на другой тип данных (кроме void *) все еще не определен. Обратите внимание, что компиляторы, соответствующие стандарту ISO C, должны генерировать предупреждение, если предпринимается попытка преобразования из указателя void * в указатель функции, как в:

 fptr = (int (*)(int))dlsym(handle, "my_function");

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

В C ++ 11 есть решение давнего несоответствия между C / C ++ и POSIX в отношении dlsym(). Можно использовать reinterpret_castдля преобразования указателя функции в / из указателя данных, если реализация поддерживает эту функцию.

Из стандарта, п. 5.2.10 п. 8, «условно поддерживается преобразование указателя функции в тип указателя объекта или наоборот». 1.3.5 определяет «условно поддерживаемую» как «конструкцию программы, которую реализация не обязана поддерживать».

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

undefined не обязательно означает «не разрешено», это может означать, что разработчик компилятора имеет больше свободы делать это так, как они хотят.

Например, это может быть невозможно на некоторых архитектурах - undefined позволяет им по-прежнему иметь соответствующую библиотеку C, даже если вы не можете этого сделать.

Другое решение:

Предполагая, что POSIX гарантирует, что указатели функций и данных имеют одинаковый размер и представление (я не могу найти текст для этого, но приведенный пример OP предполагает, что они, по крайней мере, намеревались выполнить это требование), следующее должно работать:

double (*cosine)(double);
void *tmp;
handle = dlopen("libm.so", RTLD_LAZY);
tmp = dlsym(handle, "cos");
memcpy(&cosine, &tmp, sizeof cosine);

Это позволяет избежать нарушения правил создания псевдонимов путем прохождения char []представления, которому разрешено использовать псевдонимы для всех типов.

Еще один подход:

union {
    double (*fptr)(double);
    void *dptr;
} u;
u.dptr = dlsym(handle, "cos");
cosine = u.fptr;

Но я бы порекомендовал этот memcpyподход, если вы хотите абсолютно 100% правильного C.

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

Я считаю, что они могут быть разных типов, потому что стандарт не хочет ограничивать возможные реализации, которые экономят место, когда оно не нужно или когда размер может привести к тому, что ЦП будет вынужден делать лишнюю ерунду для его использования и т. Д.

Единственное действительно переносимое решение - не использовать dlsymдля функций, а вместо этого использовать dlsymдля получения указателя на данные, содержащие указатели на функции. Например, в вашей библиотеке:

struct module foo_module = {
    .create = create_func,
    .destroy = destroy_func,
    .write = write_func,
    /* ... */
};

а затем в вашем приложении:

struct module *foo = dlsym(handle, "foo_module");
foo->create(/*...*/);
/* ... */

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

Современный пример того, где указатели функций могут отличаться по размеру от указателей данных: указатели функций-членов класса C ++

Прямая цитата из https://blogs.msdn.microsoft.com/oldnewthing/20040209-00/?p=40713/

class Base1 { int b1; void Base1Method(); };
class Base2 { int b2; void Base2Method(); };
class Derived : public Base1, Base2 { int d; void DerivedMethod(); };

Теперь есть два возможных thisуказателя.

Указатель на функцию-член Base1может использоваться как указатель на функцию-член Derived, поскольку они оба используют один и тот же this указатель. Но указатель на функцию-член Base2не может использоваться как есть в качестве указателя на функцию-член Derived, поскольку this указатель необходимо настроить.

Есть много способов решить эту проблему. Вот как компилятор Visual Studio решает справиться с этим:

Указатель на функцию-член многократно унаследованного класса на самом деле является структурой.

[Address of function]
[Adjustor]

Размер указателя на функцию-член класса, использующего множественное наследование, равен размеру указателя плюс размер size_t.

tl; dr: при использовании множественного наследования указатель на функцию-член может (в зависимости от компилятора, версии, архитектуры и т. д.) фактически храниться как

struct { 
    void * func;
    size_t offset;
}

что, очевидно, больше a void *.

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

Однако вполне возможно, что указатели функций могут потребовать другого представления, возможно, они больше, чем другие указатели. Если void * может содержать указатели на функции, это будет означать, что представление void * должно быть большего размера. И все приведения указателей данных в / из void * должны будут выполнять эту дополнительную копию.

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

Я знаю , что это не было прокомментировано с 2012 года, но я подумал , что было бы полезно добавить , что я сделать знаю архитектуру , которая имеет очень несовместимые указатели для данных и функций , так как вызов на этой архитектуру проверяет привилегию и несет дополнительную информацию. Никакой кастинг не поможет. Это мельница .