Warum sind Funktionszeiger und Datenzeiger in C / C ++ nicht kompatibel?

Ich habe gelesen, dass das Konvertieren eines Funktionszeigers in einen Datenzeiger und umgekehrt auf den meisten Plattformen funktioniert, aber nicht garantiert funktioniert. Warum ist das so? Sollten nicht beide einfach Adressen im Hauptspeicher sein und daher kompatibel sein?

Eine Architektur muss Code und Daten nicht im selben Speicher speichern. Bei einer Harvard-Architektur werden Code und Daten in einem völlig anderen Speicher gespeichert. Die meisten Architekturen sind Von Neumann-Architekturen mit Code und Daten im selben Speicher, aber C beschränkt sich nicht nur auf bestimmte Arten von Architekturen, wenn dies überhaupt möglich ist.

Einige Computer haben (hatten) separate Adressräume für Code und Daten. Auf solcher Hardware funktioniert es einfach nicht.

Die Sprache wurde nicht nur für aktuelle Desktop-Anwendungen entwickelt, sondern ermöglicht auch die Implementierung auf einer großen Menge von Hardware.

Es scheint, als hätte das C-Sprachkomitee nie beabsichtigt void*, ein Zeiger auf die Funktion zu sein, sondern nur einen generischen Zeiger auf Objekte.

Die C99-Begründung lautet:

6.3.2.3 Zeiger
C wurde jetzt auf einer Vielzahl von Architekturen implementiert. Während einige dieser Architekturen einheitliche Zeiger aufweisen, die die Größe eines ganzzahligen Typs haben, kann maximal portabler Code keine notwendige Entsprechung zwischen verschiedenen Zeigertypen und den ganzzahligen Typen annehmen. Bei einigen Implementierungen können Zeiger sogar breiter sein als jeder Ganzzahltyp.

Die Verwendung von void*("Zeiger auf void") als generischer Objektzeigertyp ist eine Erfindung des C89-Komitees. Die Übernahme dieses Typs wurde durch den Wunsch angeregt, Funktionsprototypargumente anzugeben, die entweder beliebige Zeiger (wie in fread) leise konvertieren oder sich beschweren, wenn der Argumenttyp nicht genau übereinstimmt (wie in strcmp). Über Zeiger auf Funktionen, die möglicherweise nicht mit Objektzeigern und / oder Ganzzahlen übereinstimmen, wird nichts gesagt.

Hinweis Über Zeiger auf Funktionen im letzten Absatz wird nichts gesagt . Sie können sich von anderen Hinweisen unterscheiden, und das ist sich des Ausschusses bewusst.

Für diejenigen, die sich an MS-DOS, Windows 3.1 und älter erinnern, ist die Antwort recht einfach. All dies unterstützte mehrere verschiedene Speichermodelle mit unterschiedlichen Merkmalskombinationen für Code- und Datenzeiger.

So zum Beispiel für das Compact-Modell (kleiner Code, große Datenmengen):

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

und umgekehrt im mittleren Modell (großer Code, kleine Daten):

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

In diesem Fall hatten Sie keinen separaten Speicher für Code und Datum, konnten jedoch nicht zwischen den beiden Zeigern konvertieren (ohne nicht standardmäßige Modifikatoren __near und __far).

Darüber hinaus gibt es keine Garantie dafür, dass die Zeiger, selbst wenn sie dieselbe Größe haben, auf dasselbe verweisen - im DOS Small-Speichermodell werden sowohl Code als auch Daten in der Nähe von Zeigern verwendet, sie zeigen jedoch auf unterschiedliche Segmente. Wenn Sie also einen Funktionszeiger in einen Datenzeiger konvertieren, erhalten Sie keinen Zeiger, der überhaupt eine Beziehung zur Funktion hat, und daher war eine solche Konvertierung nicht sinnvoll.

Zeiger auf ungültig sollen einen Zeiger auf jede Art von Daten aufnehmen können - aber nicht unbedingt einen Zeiger auf eine Funktion. Einige Systeme haben andere Anforderungen an Zeiger auf Funktionen als Zeiger auf Daten (z. B. gibt es DSPs mit unterschiedlicher Adressierung für Daten gegenüber Code, mittleres Modell unter MS-DOS verwendet 32-Bit-Zeiger für Code, aber nur 16-Bit-Zeiger für Daten). .

Zusätzlich zu dem, was hier bereits gesagt wurde, ist es interessant, sich POSIX anzusehen dlsym():

Der ISO C-Standard verlangt nicht, dass Zeiger auf Funktionen hin und her auf Zeiger auf Daten geworfen werden können. In der Tat verlangt der ISO C-Standard nicht, dass ein Objekt vom Typ void * einen Zeiger auf eine Funktion enthalten kann. Implementierungen, die die XSI-Erweiterung unterstützen, erfordern jedoch, dass ein Objekt vom Typ void * einen Zeiger auf eine Funktion enthalten kann. Das Ergebnis der Konvertierung eines Zeigers auf eine Funktion in einen Zeiger auf einen anderen Datentyp (außer void *) ist jedoch noch nicht definiert. Beachten Sie, dass Compiler, die dem ISO C-Standard entsprechen, eine Warnung generieren müssen, wenn eine Konvertierung von einem void * -Zeiger in einen Funktionszeiger wie folgt versucht wird:

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

Aufgrund des hier erwähnten Problems kann eine zukünftige Version entweder eine neue Funktion hinzufügen, um Funktionszeiger zurückzugeben, oder die aktuelle Schnittstelle kann zugunsten von zwei neuen Funktionen veraltet sein: eine, die Datenzeiger zurückgibt, und die andere, die Funktionszeiger zurückgibt.

C ++ 11 hat eine Lösung für die seit langem bestehende Nichtübereinstimmung zwischen C / C ++ und POSIX in Bezug auf dlsym(). Man kann reinterpret_casteinen Funktionszeiger in / von einem Datenzeiger konvertieren, solange die Implementierung diese Funktion unterstützt.

Aus dem Standard, 5.2.10 Abs. 8, "Das Konvertieren eines Funktionszeigers in einen Objektzeigertyp oder umgekehrt wird bedingt unterstützt." 1.3.5 definiert "bedingt unterstützt" als "Programmkonstrukt, für dessen Unterstützung keine Implementierung erforderlich ist".

Abhängig von der Zielarchitektur können Code und Daten in grundlegend inkompatiblen, physikalisch unterschiedlichen Speicherbereichen gespeichert werden.

undefined bedeutet nicht unbedingt nicht erlaubt, es kann bedeuten, dass der Compiler-Implementierer mehr Freiheit hat, es so zu machen, wie er will.

Beispielsweise ist dies bei einigen Architekturen möglicherweise nicht möglich. Undefiniert ermöglicht es ihnen, weiterhin über eine konforme C-Bibliothek zu verfügen, auch wenn Sie dies nicht tun können.

Eine andere Lösung:

Unter der Annahme, dass POSIX garantiert, dass Funktions- und Datenzeiger dieselbe Größe und Darstellung haben (ich kann den Text dafür nicht finden, aber das angeführte Beispiel-OP legt nahe, dass sie zumindest beabsichtigen , diese Anforderung zu erfüllen), sollte Folgendes funktionieren:

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

Dadurch wird vermieden, dass die Aliasing-Regeln verletzt werden, indem die char []Darstellung durchlaufen wird , mit der alle Typen aliasisiert werden dürfen.

Noch ein Ansatz:

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

Aber ich würde den memcpyAnsatz empfehlen, wenn Sie absolut 100% korrektes C wollen.

Es können verschiedene Typen mit unterschiedlichem Platzbedarf sein. Das Zuweisen zu einem kann den Wert des Zeigers irreversibel aufteilen, sodass das Zurückweisen zu etwas anderem führt.

Ich glaube, es können verschiedene Typen sein, weil der Standard mögliche Implementierungen nicht einschränken möchte, die Platz sparen, wenn sie nicht benötigt werden oder wenn die Größe dazu führen kann, dass die CPU zusätzlichen Mist machen muss, um sie zu verwenden, usw.

Die einzige wirklich tragbare Lösung besteht darin, sie nicht dlsymfür Funktionen zu verwenden, sondern stattdessen dlsymeinen Zeiger auf Daten zu erhalten, die Funktionszeiger enthalten. Zum Beispiel in Ihrer Bibliothek:

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

und dann in Ihrer Bewerbung:

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

Im Übrigen ist dies ohnehin eine gute Entwurfspraxis und erleichtert die Unterstützung des dynamischen Ladens über dlopenund der statischen Verknüpfung aller Module auf Systemen, die keine dynamische Verknüpfung unterstützen oder bei denen der Benutzer / Systemintegrator keine dynamische Verknüpfung verwenden möchte.

Ein modernes Beispiel dafür, wo sich Funktionszeiger in der Größe von Datenzeigern unterscheiden können: C ++ - Klassenmitgliedsfunktionszeiger

Direkt zitiert von 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(); };

Es gibt jetzt zwei mögliche thisZeiger.

Ein Zeiger auf eine Mitgliedsfunktion von Base1kann als Zeiger auf eine Mitgliedsfunktion von verwendet werden Derived, da beide denselben this Zeiger verwenden. Ein Zeiger auf eine Elementfunktion von Base2kann jedoch nicht unverändert als Zeiger auf eine Elementfunktion von verwendet werden Derived, da der this Zeiger angepasst werden muss.

Es gibt viele Möglichkeiten, dies zu lösen. So entscheidet sich der Visual Studio-Compiler dafür:

Ein Zeiger auf eine Mitgliedsfunktion einer mehrfach vererbten Klasse ist wirklich eine Struktur.

[Address of function]
[Adjustor]

Die Größe einer Zeiger-zu-Mitglied-Funktion einer Klasse, die Mehrfachvererbung verwendet, entspricht der Größe eines Zeigers plus der Größe von a size_t.

tl; dr: Bei Verwendung der Mehrfachvererbung kann ein Zeiger auf eine Mitgliedsfunktion (abhängig von Compiler, Version, Architektur usw.) tatsächlich als gespeichert werden

struct { 
    void * func;
    size_t offset;
}

das ist offensichtlich größer als a void *.

Auf den meisten Architekturen haben Zeiger auf alle normalen Datentypen dieselbe Darstellung, sodass das Umwandeln zwischen Datenzeigertypen ein No-Op ist.

Es ist jedoch denkbar, dass Funktionszeiger eine andere Darstellung erfordern, möglicherweise sind sie größer als andere Zeiger. Wenn void * Funktionszeiger enthalten könnte, würde dies bedeuten, dass die Darstellung von void * größer sein müsste. Und alle Abgüsse von Datenzeigern auf / von void * müssten diese zusätzliche Kopie ausführen.

Wie bereits erwähnt, können Sie dies bei Bedarf mithilfe einer Gewerkschaft erreichen. Die meisten Verwendungen von void * beziehen sich jedoch nur auf Daten. Daher wäre es mühsam, die gesamte Speichernutzung zu erhöhen, falls ein Funktionszeiger gespeichert werden muss.

Ich weiß , dass dies nicht auf seit 2012 kommentiert worden, aber ich dachte , es wäre nützlich , hinzufügen , dass ich tun wissen , eine Architektur , die hat sehr auf dieser Architektur überprüft Privileg , da einen Anruf nicht kompatibel Zeiger für Daten und Funktionen und führt zusätzliche Informationen. Keine Menge Casting wird helfen. Es ist die Mühle .