Dlaczego wskaźniki funkcji i wskaźniki danych są niezgodne w C / C ++?

Czytałem, że konwersja wskaźnika funkcji na wskaźnik danych i odwrotnie działa na większości platform, ale nie gwarantuje, że zadziała. Dlaczego tak się dzieje? Czy oba nie powinny być po prostu adresami do pamięci głównej, a zatem powinny być kompatybilne?

Architektura nie musi przechowywać kodu i danych w tej samej pamięci. W architekturze Harvardu kod i dane są przechowywane w zupełnie innej pamięci. Większość architektur to architektury Von Neumanna z kodem i danymi w tej samej pamięci, ale C nie ogranicza się tylko do pewnych typów architektur, jeśli to w ogóle możliwe.

Niektóre komputery mają (miały) oddzielne przestrzenie adresowe dla kodu i danych. Na takim sprzęcie to po prostu nie działa.

Język jest przeznaczony nie tylko dla obecnych aplikacji desktopowych, ale także w celu umożliwienia implementacji na dużym zestawie sprzętu.

Wygląda na to, że komitet języka C nigdy nie zamierzał void*być wskaźnikiem do działania, po prostu chciał mieć ogólny wskaźnik do obiektów.

Uzasadnienie C99 mówi:

6.3.2.3 Wskaźniki
C zostały już zaimplementowane w wielu różnych architekturach. Podczas gdy niektóre z tych architektur mają jednolite wskaźniki, które mają rozmiar pewnego typu całkowitego, maksymalnie przenośny kod nie może zakładać żadnej niezbędnej zgodności między różnymi typami wskaźników i typami całkowitymi. W niektórych implementacjach wskaźniki mogą być nawet szersze niż jakikolwiek typ liczb całkowitych.

Użycie void*(„pointer to void”) jako ogólnego typu wskaźnika do obiektu jest wynalazkiem Komitetu C89. Przyjęcie tego typu było stymulowane chęcią określenia argumentów prototypu funkcji, które albo po cichu konwertują dowolne wskaźniki (jak w fread), albo narzekają, jeśli typ argumentu nie jest dokładnie zgodny (jak w strcmp). Nie mówi się nic o wskaźnikach do funkcji, które mogą być niewspółmierne do wskaźników obiektów i / lub liczb całkowitych.

Uwaga W ostatnim akapicie nic nie jest powiedziane o wskaźnikach do funkcji . Mogą różnić się od innych wskazówek, a komisja jest tego świadoma.

Dla tych, którzy pamiętają MS-DOS, Windows 3.1 i starsze, odpowiedź jest dość prosta. Wszystkie z nich były używane do obsługi kilku różnych modeli pamięci, z różnymi kombinacjami charakterystyk kodu i wskaźników danych.

Na przykład dla modelu Compact (mały kod, duże dane):

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

i odwrotnie w modelu Medium (duży kod, małe dane):

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

W tym przypadku nie miałeś oddzielnego miejsca na kod i datę, ale nadal nie mogłeś konwertować między dwoma wskaźnikami (bez użycia niestandardowych modyfikatorów __near i __far).

Dodatkowo nie ma gwarancji, że nawet jeśli wskaźniki są tego samego rozmiaru, wskazują na to samo - w modelu DOS Small memory zarówno kod, jak i dane używane w pobliżu wskaźników, ale wskazywały na różne segmenty. Zatem konwersja wskaźnika funkcji na wskaźnik danych nie dałaby wskaźnika, który w ogóle miałby związek z funkcją, a zatem taka konwersja nie miała sensu.

Wskaźniki do void mają być w stanie pomieścić wskaźnik do dowolnego rodzaju danych - ale niekoniecznie wskaźnik do funkcji. Niektóre systemy mają inne wymagania dotyczące wskaźników do funkcji niż wskaźniki do danych (np. Istnieją procesory DSP o różnym adresowaniu danych w porównaniu z kodem, model medium w systemie MS-DOS wykorzystywał 32-bitowe wskaźniki do kodu, ale tylko 16-bitowe wskaźniki do danych) .

Oprócz tego, co zostało już tutaj powiedziane, warto przyjrzeć się POSIX dlsym():

Norma ISO C nie wymaga, aby wskaźniki do funkcji można było rzutować tam iz powrotem na wskaźniki do danych. Rzeczywiście, standard ISO C nie wymaga, aby obiekt typu void * mógł trzymać wskaźnik do funkcji. Implementacje obsługujące rozszerzenie XSI wymagają jednak, aby obiekt typu void * mógł przechowywać wskaźnik do funkcji. Wynik konwersji wskaźnika na funkcję we wskaźnik do innego typu danych (z wyjątkiem void *) jest jednak nadal niezdefiniowany. Zauważ, że kompilatory zgodne ze standardem ISO C są zobowiązane do generowania ostrzeżenia, jeśli zostanie podjęta próba konwersji ze wskaźnika void * na wskaźnik funkcji, jak w:

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

Ze względu na opisany tutaj problem, przyszła wersja może albo dodać nową funkcję zwracającą wskaźniki funkcji, albo obecny interfejs może zostać wycofany na rzecz dwóch nowych funkcji: jednej zwracającej wskaźniki danych, a drugiej zwracającej wskaźniki funkcji.

C ++ 11 ma rozwiązanie długotrwałej niezgodności między C / C ++ i POSIX w odniesieniu do dlsym(). Można użyć reinterpret_castdo konwersji wskaźnika funkcji na / ze wskaźnika danych, o ile implementacja obsługuje tę funkcję.

Ze standardu 5.2.10 ust. 8, „konwersja wskaźnika funkcji na typ wskaźnika obiektu lub odwrotnie jest obsługiwana warunkowo”. 1.3.5 definiuje „warunkowo obsługiwane” jako „konstrukcję programu, której obsługa nie jest wymagana”.

W zależności od docelowej architektury, kod i dane mogą być przechowywane w zasadniczo niekompatybilnych, fizycznie odrębnych obszarach pamięci.

undefined niekoniecznie oznacza niedozwolone, może to oznaczać, że implementujący kompilator ma większą swobodę, aby zrobić to tak, jak chce.

Na przykład może to nie być możliwe na niektórych architekturach - undefined pozwala im nadal mieć zgodną bibliotekę „C”, nawet jeśli nie możesz tego zrobić.

Inne rozwiązanie:

Zakładając, że POSIX gwarantuje, że wskaźniki funkcji i danych mają ten sam rozmiar i reprezentację (nie mogę znaleźć tekstu do tego, ale cytowany przykład OP sugeruje, że przynajmniej zamierzali spełnić to wymaganie), następujące działania powinny działać:

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

Zapobiega to naruszaniu reguł aliasingu poprzez przeglądanie char []reprezentacji, która może aliasować wszystkie typy.

Jeszcze inne podejście:

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

Ale poleciłbym to memcpypodejście, jeśli chcesz absolutnie w 100% poprawne C.

Mogą to być różne typy z różnymi wymaganiami dotyczącymi miejsca. Przypisanie do jednego z nich może nieodwracalnie przeciąć wartość wskaźnika, tak że przypisanie z powrotem spowoduje coś innego.

Uważam, że mogą to być różne typy, ponieważ standard nie chce ograniczać możliwych implementacji, które oszczędzają miejsce, gdy nie jest to potrzebne lub gdy rozmiar może spowodować, że procesor będzie musiał robić dodatkowe bzdury, aby go użyć itp.

Jedynym naprawdę przenośnym rozwiązaniem jest nie używanie dlsymdo funkcji, a zamiast tego użycie dlsymdo uzyskania wskaźnika do danych, które zawierają wskaźniki funkcji. Na przykład w Twojej bibliotece:

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

a następnie w aplikacji:

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

Nawiasem mówiąc, jest to i tak dobra praktyka projektowa, która ułatwia obsługę zarówno dynamicznego ładowania przez, jak dlopeni statycznego łączenia wszystkich modułów w systemach, które nie obsługują dynamicznego łączenia, lub gdy użytkownik / integrator systemu nie chce używać dynamicznego łączenia.

Nowoczesny przykład, w którym wskaźniki funkcji mogą różnić się rozmiarem od wskaźników danych: wskaźniki funkcji składowych klasy C ++

Cytowane bezpośrednio z 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(); };

Istnieją teraz dwie możliwe thiswskazówki.

Wskaźnik do funkcji składowej Base1może być używany jako wskaźnik do funkcji składowej Derived, ponieważ oba używają tego samego this wskaźnika. Jednak wskaźnik do funkcji Base2składowej nie może być używany jako wskaźnik do funkcji składowej programu Derived, ponieważ this wskaźnik wymaga dostosowania.

Istnieje wiele sposobów rozwiązania tego problemu. Oto, jak kompilator programu Visual Studio decyduje się to obsłużyć:

Wskaźnik do funkcji składowej klasy dziedziczonej wielokrotnie jest w rzeczywistości strukturą.

[Address of function]
[Adjustor]

Rozmiar funkcji wskaźnika do elementu członkowskiego klasy, która korzysta z dziedziczenia wielokrotnego, to rozmiar wskaźnika plus rozmiar a size_t.

tl; dr: Podczas korzystania z dziedziczenia wielokrotnego wskaźnik do funkcji składowej może (w zależności od kompilatora, wersji, architektury itp.) W rzeczywistości być przechowywany jako

struct { 
    void * func;
    size_t offset;
}

który jest oczywiście większy niż void *.

Na większości architektur wskaźniki do wszystkich normalnych typów danych mają tę samą reprezentację, więc rzutowanie między typami wskaźników danych nie jest możliwe.

Jednak można sobie wyobrazić, że wskaźniki funkcji mogą wymagać innej reprezentacji, być może są większe niż inne wskaźniki. Gdyby void * mógł przechowywać wskaźniki funkcji, oznaczałoby to, że reprezentacja void * musiałaby mieć większy rozmiar. Wszystkie rzuty wskaźników danych do / z void * musiałyby wykonać tę dodatkową kopię.

Jak ktoś wspomniał, jeśli tego potrzebujesz, możesz to osiągnąć za pomocą związku. Jednak większość zastosowań void * dotyczy tylko danych, więc zwiększenie całkowitego wykorzystania pamięci na wypadek konieczności zapisania wskaźnika funkcji byłoby uciążliwe.

Wiem, że nie zostało to skomentował od 2012 roku, ale pomyślałem, że warto byłoby dodać, że zrobić znać architekturę, która ma bardzo niekompatybilne odnośniki do danych i funkcji, ponieważ rozmowy na ten przywilej sprawdza architektura i niesie dodatkowe informacje. Żadna ilość rzucania nie pomoże. To jest młyn .