Чому функції покажчиків та покажчиків даних несумісні в 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(*)())

і навпаки в моделі "Середній" (великий код, невеликі дані):

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

У цьому випадку у вас не було окремого сховища для коду та дати, але все ще не вдалося конвертувати між двома вказівниками (окрім використання нестандартних модифікаторів __near та __far).

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

Вказівники на недійсність повинні вміщувати покажчик на будь-який тип даних, але не обов'язково вказівник на функцію. Деякі системи мають інші вимоги до покажчиків функцій, ніж покажчики на дані (наприклад, є ЦСП з різною адресацією для даних проти коду; середня модель в MS-DOS використовується 32-бітні покажчики на код, але лише 16-бітні вказівники для даних) .

Окрім сказаного тут, цікаво подивитися на POSIX dlsym():

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

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

Через проблему, зазначену тут, майбутня версія може або додати нову функцію для повернення функціональних покажчиків, або поточний інтерфейс може бути застарілим на користь двох нових функцій: однієї, яка повертає покажчики даних, і іншої, що повертає покажчики функцій.

C ++ 11 має рішення щодо давньої невідповідності між C / C ++ та POSIX стосовно dlsym(). Можна reinterpret_castперетворити покажчик функції на / з вказівника даних до тих пір, поки реалізація підтримує цю функцію.

Зі стандарту, 5.2.10 абз. 8, "перетворення покажчика функції на тип об'єктного вказівника або навпаки умовно підтримується." 1.3.5 визначає "умовно підтримуваний" як "конструктор програми, яка не потребує підтримки для підтримки".

Залежно від цільової архітектури, код і дані можуть зберігатися у принципово несумісних, фізично відмінних областях пам'яті.

undefined не обов'язково означає, що не дозволено, це може означати, що у виконавця компілятора є більше свободи робити це так, як вони хочуть.

Наприклад, це може бути неможливим для деяких архітектур - невизначений дозволяє їм все ще мати відповідну бібліотеку "C", навіть якщо ви не можете цього зробити.

Ще одне рішення:

Якщо припустити, що POSIX гарантує, що функції та покажчики даних мають однаковий розмір і представлення (я не можу знайти текст для цього, але приведений приклад ОП дозволяє припустити, що вони принаймні мають на меті висунути цю вимогу), слід працювати наступним чином:

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]

Розмір функції вказівника на члена класу, який використовує множинне успадкування, є розміром покажчика плюс розмір a size_t.

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

struct { 
    void * func;
    size_t offset;
}

яка, очевидно, більша за a void *.

У більшості архітектур вказівники на всі звичайні типи даних мають однакове представлення, тому кастинг між типами покажчиків даних є необов'язковим.

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

Як хтось згадував, якщо вам це потрібно, ви можете досягти цього, використовуючи союз. Але більшість застосувань void * призначені лише для даних, тому було б важко збільшити все їх пам’ять на випадок, якщо потрібний вказівник функції зберігається.

Я знаю , що це не було прокоментовано з 2012 року, але я подумав , що було б корисно додати , що я зробити знаю архітектуру , яка має дуже несумісні покажчики для даних і функцій , так як виклик на цій архітектуру перевіряє привілей і несе додаткову інформацію. Жодна кількість кастингу не допоможе. Це млин .