Perché i puntatori a funzione e puntatori a dati non sono compatibili in C / C ++?

Ho letto che convertire un puntatore a funzione in un puntatore dati e viceversa funziona sulla maggior parte delle piattaforme ma non è garantito che funzioni. Perché è così? Entrambi non dovrebbero essere semplicemente indirizzi nella memoria principale e quindi essere compatibili?

Un'architettura non deve archiviare codice e dati nella stessa memoria. Con un'architettura di Harvard, codice e dati sono archiviati in una memoria completamente diversa. La maggior parte delle architetture sono architetture di Von Neumann con codice e dati nella stessa memoria, ma C non si limita a determinati tipi di architetture, se possibile.

Alcuni computer hanno (avevano) spazi di indirizzi separati per codice e dati. Su tale hardware non funziona.

Il linguaggio è progettato non solo per le attuali applicazioni desktop, ma per consentirne l'implementazione su un ampio set di hardware.

Sembra che il comitato del linguaggio C non abbia mai voluto void*essere un puntatore per funzionare, volevano solo un puntatore generico agli oggetti.

La logica C99 dice:

6.3.2.3 I puntatori
C sono stati ora implementati su una vasta gamma di architetture. Mentre alcune di queste architetture presentano puntatori uniformi delle dimensioni di un tipo intero, il codice al massimo portatile non può assumere alcuna corrispondenza necessaria tra diversi tipi di puntatore e tipi interi. In alcune implementazioni, i puntatori possono persino essere più larghi di qualsiasi tipo intero.

L'uso di void*("puntatore a void") come tipo di puntatore oggetto generico è un'invenzione del comitato C89. L'adozione di questo tipo è stata stimolata dal desiderio di specificare argomenti prototipo di funzione che convertano silenziosamente puntatori arbitrari (come in fread) o si lamentano se il tipo di argomento non corrisponde esattamente (come in strcmp). Non si dice nulla sui puntatori alle funzioni, che potrebbero essere incompatibili con i puntatori agli oggetti e / o numeri interi.

Nota Non si dice nulla sui puntatori alle funzioni nell'ultimo paragrafo. Potrebbero essere diversi dagli altri suggerimenti, e il comitato ne è consapevole.

Per coloro che ricordano MS-DOS, Windows 3.1 e precedenti, la risposta è abbastanza semplice. Tutti utilizzati per supportare diversi modelli di memoria, con diverse combinazioni di caratteristiche per puntatori di codice e dati.

Ad esempio, per il modello Compact (codice piccolo, dati di grandi dimensioni):

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

e viceversa nel modello Medium (codice grande, dati piccoli):

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

In questo caso non avevi spazio di archiviazione separato per codice e data ma non riuscivi ancora a convertire tra i due puntatori (a meno di usare modificatori __near e __far non standard).

Inoltre, non c'è alcuna garanzia che anche se i puntatori hanno le stesse dimensioni, indicano la stessa cosa: nel modello di memoria piccola DOS, sia il codice che i dati usati vicino ai puntatori, ma hanno indicato segmenti diversi. Quindi la conversione di un puntatore a funzione in un puntatore dati non ti darebbe un puntatore che non avesse alcuna relazione con la funzione, e quindi non era utile per tale conversione.

I puntatori da annullare dovrebbero essere in grado di ospitare un puntatore a qualsiasi tipo di dati, ma non necessariamente un puntatore a una funzione. Alcuni sistemi hanno requisiti diversi per i puntatori alle funzioni rispetto ai puntatori ai dati (ad esempio, ci sono DSP con indirizzamento diverso per dati vs. codice, modello medio su MS-DOS utilizzava puntatori a 32 bit per il codice ma solo puntatori a 16 bit per i dati) .

Oltre a quanto già detto qui, è interessante guardare POSIX dlsym():

Lo standard ISO C non richiede che i puntatori alle funzioni possano essere trasmessi avanti e indietro ai puntatori ai dati. In effetti, lo standard ISO C non richiede che un oggetto di tipo void * possa contenere un puntatore a una funzione. Le implementazioni che supportano l'estensione XSI, tuttavia, richiedono che un oggetto di tipo void * possa contenere un puntatore a una funzione. Tuttavia, il risultato della conversione di un puntatore in una funzione in un puntatore in un altro tipo di dati (tranne void *) non è ancora definito. Si noti che i compilatori conformi allo standard ISO C sono tenuti a generare un avviso se si tenta una conversione da un puntatore void * a un puntatore a funzione come in:

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

A causa del problema notato qui, una versione futura può aggiungere una nuova funzione per restituire i puntatori a funzione oppure l'interfaccia attuale può essere deprecata a favore di due nuove funzioni: una che restituisce puntatori di dati e l'altra che restituisce puntatori di funzioni.

C ++ 11 ha una soluzione al disadattamento di vecchia data tra C / C ++ e POSIX per quanto riguarda dlsym(). È possibile utilizzare reinterpret_castper convertire un puntatore a funzione da / a un puntatore dati purché l'implementazione supporti questa funzionalità.

Dallo standard, 5.2.10 para. 8, "la conversione di un puntatore a funzione in un tipo di puntatore oggetto o viceversa è supportata in modo condizionale". 1.3.5 definisce "il supporto condizionato" come un "costrutto di programma che non è richiesto un supporto per l'implementazione".

A seconda dell'architettura di destinazione, codice e dati possono essere archiviati in aree di memoria sostanzialmente incompatibili e fisicamente distinte.

undefined non significa necessariamente non permesso, può significare che l'implementatore del compilatore ha più libertà di farlo come vuole.

Ad esempio, potrebbe non essere possibile su alcune architetture: undefined consente loro di avere ancora una libreria 'C' conforme anche se non è possibile farlo.

Un'altra soluzione:

Supponendo che POSIX garantisca che i puntatori di funzione e dati abbiano le stesse dimensioni e rappresentazione (non riesco a trovare il testo per questo, ma l'esempio OP citato suggerisce che almeno intendono soddisfare questo requisito), dovrebbe funzionare quanto segue:

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

Questo evita di violare le regole di alias passando attraverso la char []rappresentazione, che è autorizzata ad alias tutti i tipi.

Ancora un altro approccio:

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

Ma consiglierei l' memcpyapproccio se vuoi assolutamente il 100% corretto C.

Possono essere di tipi diversi con requisiti di spazio diversi. L'assegnazione a uno può dividere in modo irreversibile il valore del puntatore in modo che l'assegnazione restituisca risultati diversi.

Credo che possano essere di diversi tipi perché lo standard non vuole limitare possibili implementazioni che risparmiano spazio quando non è necessario o quando le dimensioni potrebbero far sì che la CPU debba fare una cazzata extra per usarlo, ecc ...

L'unica soluzione veramente portatile non è quella di utilizzare le dlsymfunzioni, ma invece dlsymdi ottenere un puntatore a dati che contengono puntatori di funzioni. Ad esempio, nella tua libreria:

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

e quindi nella tua applicazione:

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

Per inciso, questa è comunque una buona pratica di progettazione e semplifica il supporto sia del caricamento dinamico tramite dlopene del collegamento statico di tutti i moduli su sistemi che non supportano il collegamento dinamico, sia in cui l'utente / integratore di sistema non desidera utilizzare il collegamento dinamico.

Un esempio moderno di dove i puntatori a funzione possono differire in dimensioni da puntatori di dati: puntatori a funzioni membro della classe C ++

Citato direttamente da 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(); };

Ora ci sono due possibili thispuntatori.

Un puntatore a una funzione membro di Base1può essere utilizzato come puntatore a una funzione membro di Derived, poiché entrambi utilizzano lo stesso this puntatore. Ma un puntatore a una funzione membro di Base2non può essere usato così com'è come un puntatore a una funzione membro di Derived, poiché il this puntatore deve essere regolato.

Esistono molti modi per risolverlo. Ecco come il compilatore di Visual Studio decide di gestirlo:

Un puntatore a una funzione membro di una classe ereditata moltiplicata è in realtà una struttura.

[Address of function]
[Adjustor]

La dimensione di una funzione da puntatore a membro di una classe che utilizza l'ereditarietà multipla è la dimensione di un puntatore più la dimensione di a size_t.

tl; dr: quando si utilizza l'ereditarietà multipla, un puntatore a una funzione membro può (in base al compilatore, alla versione, all'architettura, ecc.) essere effettivamente archiviato come

struct { 
    void * func;
    size_t offset;
}

che è ovviamente più grande di a void *.

Sulla maggior parte delle architetture, i puntatori a tutti i normali tipi di dati hanno la stessa rappresentazione, quindi il cast tra tipi di puntatori di dati non è consentito.

Tuttavia, è concepibile che i puntatori a funzione potrebbero richiedere una rappresentazione diversa, forse sono più grandi di altri puntatori. Se void * potesse contenere puntatori a funzioni, ciò significherebbe che la rappresentazione di void * dovrebbe avere dimensioni maggiori. E tutti i cast di puntatori di dati verso / da void * dovrebbero eseguire questa copia aggiuntiva.

Come qualcuno ha detto, se hai bisogno di questo puoi ottenerlo usando un sindacato. Ma la maggior parte degli usi di void * sono solo per i dati, quindi sarebbe oneroso aumentare tutto il loro uso della memoria nel caso in cui sia necessario memorizzare un puntatore a funzione.

So che questo non è stato commentato dal 2012, ma ho pensato che sarebbe stato utile aggiungere che io faccio sapere un'architettura che ha molto puntatori incompatibili per i dati e le funzioni in quanto una chiamata su quella architettura controlli privilegio e trasporta informazioni extra. Nessuna quantità di casting sarà di aiuto. È il mulino .