size_t vs. uintptr_t

Lo standard C garantisce che size_tè un tipo che può contenere qualsiasi indice di array. Ciò significa che, logicamente, size_tdovrebbe essere in grado di contenere qualsiasi tipo di puntatore. Ho letto su alcuni siti che ho trovato su Google che questo è legale e / o dovrebbe sempre funzionare:

void *v = malloc(10);
size_t s = (size_t) v;

Quindi, in C99, lo standard ha introdotto i tipi intptr_te uintptr_t, che sono tipi firmati e non firmati garantiti per essere in grado di contenere i puntatori:

uintptr_t p = (size_t) v;

Quindi qual è la differenza tra l'utilizzo di size_te uintptr_t? Entrambi sono senza segno ed entrambi dovrebbero essere in grado di contenere qualsiasi tipo di puntatore, quindi sembrano funzionalmente identici. C'è qualche vero motivo convincente da usare uintptr_t(o meglio ancora, a void *) piuttosto che a size_t, oltre alla chiarezza? In una struttura opaca, in cui il campo sarà gestito solo da funzioni interne, c'è qualche motivo per non farlo?

Allo stesso modo, ptrdiff_tè stato un tipo con segno in grado di contenere le differenze di puntatore e quindi in grado di contenere la maggior parte di qualsiasi puntatore, quindi come si distingue intptr_t?

Tutti questi tipi non servono sostanzialmente versioni banalmente diverse della stessa funzione? Se no, perché? Cosa non posso fare con uno di loro che non posso fare con un altro? In tal caso, perché C99 ha aggiunto due tipi essenzialmente superflui alla lingua?

Sono disposto a ignorare i puntatori alle funzioni, poiché non si applicano al problema attuale, ma sono libero di menzionarli, poiché ho il sospetto che saranno fondamentali per la risposta "corretta".

size_tè un tipo che può contenere qualsiasi indice di array. Ciò significa che, logicamente, size_t dovrebbe essere in grado di contenere qualsiasi tipo di puntatore

Non necessariamente! Torniamo ai giorni delle architetture segmentate a 16 bit per esempio: un array potrebbe essere limitato a un singolo segmento (quindi un 16 bit size_tfarebbe) MA potresti avere più segmenti (quindi intptr_tsarebbe necessario un tipo a 32 bit per scegliere il segmento e l'offset al suo interno). So che queste cose suonano strane in questi giorni di architetture non segmentate indirizzabili in modo uniforme, ma lo standard DEVE soddisfare una varietà più ampia di "ciò che è normale nel 2009", lo sai! -)

Per quanto riguarda la tua dichiarazione:

"Lo standard C garantisce che size_tè un tipo che può contenere qualsiasi indice di array. Ciò significa che, logicamente, size_tdovrebbe essere in grado di contenere qualsiasi tipo di puntatore."

Questo è in realtà un errore (un equivoco derivante da un ragionamento errato) ^(a) . Potresti pensare che il secondo derivi dal primo, ma in realtà non è così.

Puntatori e indici di array non sono la stessa cosa. È abbastanza plausibile prevedere un'implementazione conforme che limiti gli array a 65536 elementi ma consente ai puntatori di indirizzare qualsiasi valore in un enorme spazio di indirizzi a 128 bit.

C99 afferma che il limite superiore di una size_tvariabile è definito da SIZE_MAXe questo può essere fino a 65535 (vedere C99 TR3, 7.18.3, invariato in C11). I puntatori sarebbero abbastanza limitati se fossero limitati a questa gamma nei sistemi moderni.

In pratica, probabilmente scoprirai che il tuo presupposto è valido, ma non perché lo standard lo garantisca. Perché in realtà non lo garantisce.

^(a) A proposito, questa non è una forma di attacco personale, affermando semplicemente perché le tue affermazioni sono errate nel contesto del pensiero critico. Ad esempio, anche il seguente ragionamento non è valido:

Tutti i cuccioli sono carini. Questa cosa è carina Quindi questa cosa deve essere un cucciolo.

La carineria o meno del puppiess non ha rilevanza qui, tutto ciò che sto affermando è che i due fatti non portano alla conclusione, perché le prime due frasi consentono l'esistenza di cose carine che non sono cuccioli.

Questo è simile alla tua prima affermazione che non richiede necessariamente la seconda.

Lascerò tutte le altre risposte autonome per quanto riguarda il ragionamento con limiti di segmento, architetture esotiche e così via.

La semplice differenza nei nomi non è sufficiente per usare il tipo giusto per la cosa giusta?

Se stai memorizzando una dimensione, usa size_t. Se stai memorizzando un puntatore, usa intptr_t. Una persona che legge il tuo codice saprà immediatamente che "ah, questa è una dimensione di qualcosa, probabilmente in byte", e "oh, ecco un valore del puntatore che viene memorizzato come numero intero, per qualche motivo".

Altrimenti, potresti semplicemente usare unsigned long(o, in questi tempi moderni, unsigned long long) per tutto. La dimensione non è tutto, i nomi dei tipi hanno un significato che è utile poiché aiuta a descrivere il programma.

È possibile che la dimensione dell'array più grande sia più piccola di un puntatore. Pensa alle architetture segmentate: i puntatori possono essere a 32 bit, ma un singolo segmento potrebbe essere in grado di indirizzare solo 64 KB (ad esempio la vecchia architettura 8086 in modalità reale).

Sebbene questi non siano più comunemente utilizzati nelle macchine desktop, lo standard C è destinato a supportare anche piccole architetture specializzate. Ad esempio, esistono ancora sistemi embedded sviluppati con CPU a 8 o 16 bit.

Immagino (e questo vale per tutti i nomi di tipo) che trasmette meglio le tue intenzioni in codice.

Ad esempio, anche se unsigned shorte wchar_tho le stesse dimensioni su Windows (penso), usando wchar_tinvece di unsigned shortmostrare l'intenzione che lo userete per memorizzare un carattere largo, piuttosto che solo un numero arbitrario.

Guardando avanti e indietro, e ricordando che varie architetture strane erano sparse per il paesaggio, sono abbastanza sicuro che stessero cercando di avvolgere tutti i sistemi esistenti e fornire anche tutti i possibili sistemi futuri.

Di certo, nel modo in cui le cose si sono sistemate, finora non abbiamo avuto bisogno di così tanti tipi.

Ma anche in LP64, un paradigma piuttosto comune, avevamo bisogno di size_t e ssize_t per l'interfaccia di chiamata di sistema. Si può immaginare un sistema legacy o futuro più vincolato, in cui l'utilizzo di un tipo a 64 bit è costoso e potrebbero voler puntare su operazioni di I / O più grandi di 4 GB ma avere ancora puntatori a 64 bit.

Penso che devi chiederti: cosa potrebbe essere stato sviluppato, cosa potrebbe venire in futuro. (Forse puntatori a livello di sistema distribuito a 128 bit su Internet, ma non più di 64 bit in una chiamata di sistema, o forse anche un limite "legacy" a 32 bit. :-) Immagine che i sistemi legacy potrebbero ottenere nuovi compilatori C. .

Inoltre, guarda cosa esisteva allora. Oltre ai milioni di modelli di memoria in modalità reale 286, che ne dite dei mainframe CDC 60 bit / 18 bit puntatore? Che ne dici della serie Cray? Non importa il normale ILP64, LP64, LLP64. (Ho sempre pensato che Microsoft fosse pretenzioso con LLP64, avrebbe dovuto essere P64.) Posso certamente immaginare un comitato che cerca di coprire tutte le basi ...

int main(){
  int a[4]={0,1,5,3};
  int a0 = a[0];
  int a1 = *(a+1);
  int a2 = *(2+a);
  int a3 = 3[a];
  return a2;
}

Implica che intptr_t debba sempre sostituire size_t e viceversa.