size_t vs. uintptr_t

Question

La norme C garantit que size_t est un type qui peut contenir n'importe quel indice de tableau. Cela signifie que, logiquement, size_t doit pouvoir contenir n'importe quel type de pointeur. J'ai lu sur certains sites que j'ai trouvés sur Google que cela est légal et/ou devrait toujours fonctionner :

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

Ainsi, en C99, la norme a introduit la fonction intptr_t et uintptr_t qui sont des types signés et non signés dont la capacité à contenir des pointeurs est garantie :

uintptr_t p = (size_t) v;

Alors quelle est la différence entre utiliser size_t et uintptr_t ? Les deux sont non signés, et les deux devraient pouvoir contenir n'importe quel type de pointeur, donc ils semblent fonctionnellement identiques. Y a-t-il une raison impérieuse d'utiliser uintptr_t (ou mieux encore, un void * ) plutôt qu'un size_t à part la clarté ? Dans une structure opaque, où le champ ne sera traité que par des fonctions internes, y a-t-il une raison de ne pas le faire ?

Dans le même ordre d'idées, ptrdiff_t a été un type signé capable de contenir des différences de pointeurs, et donc capable de contenir la plupart des pointeurs, alors comment se distingue-t-il de intptr_t ?

Tous ces types ne servent-ils pas essentiellement des versions trivialement différentes de la même fonction ? Si ce n'est pas le cas, pourquoi ? Qu'est-ce que je ne peux pas faire avec l'un d'eux que je ne peux pas faire avec un autre ? Si oui, pourquoi C99 a ajouté deux types essentiellement superflus au langage ?

Je suis prêt à ne pas tenir compte des pointeurs de fonction, car ils ne s'appliquent pas au problème actuel, mais n'hésitez pas à les mentionner, car je soupçonne qu'ils seront essentiels à la "bonne" réponse.

Answer 1

size_t est un type qui peut contenir n'importe quel indice de tableau. Cela signifie que, logiquement, size_t devrait être capable de contenir n'importe quel type de pointeur

Pas forcément ! Revenons à l'époque des architectures 16 bits segmentées, par exemple : un tableau pouvait être limité à un seul segment (donc un tableau 16 bits size_t ferait l'affaire) MAIS vous pourriez avoir plusieurs segments (donc un segment de 32-bit intptr_t serait nécessaire pour choisir le segment ainsi que le décalage à l'intérieur de celui-ci). Je sais que ces choses semblent bizarres en ces jours d'architectures non segmentées uniformément adressables, mais la norme DOIT répondre à une variété plus large que "ce qui est normal en 2009", vous savez !-)

Answer 2

En ce qui concerne votre déclaration :

"La norme C garantit que size_t est un type qui peut contenir n'importe quel indice de tableau. Cela signifie que, logiquement, size_t devrait pouvoir contenir n'importe quel type de pointeur."

Il s'agit en fait d'un sophisme (une idée fausse résultant d'un raisonnement incorrect). (a) . Vous pouvez pensez à le second découle du premier, mais ce n'est pas vraiment le cas.

Les pointeurs et les index de tableaux sont pas la même chose. Il est tout à fait plausible d'envisager une mise en œuvre conforme qui limite les tableaux à 65536 éléments mais autorise les pointeurs à adresser n'importe quelle valeur dans un espace d'adressage massif de 128 bits.

La norme C99 stipule que la limite supérieure d'un size_t La variable est définie par SIZE_MAX et cette valeur peut être aussi basse que 65535 (voir C99 TR3, 7.18.3, inchangé en C11). Les pointeurs seraient assez limités s'ils étaient restreints à cette plage dans les systèmes modernes.

En pratique, vous constaterez probablement que votre hypothèse se vérifie, mais ce n'est pas parce que la norme le garantit. Parce qu'elle n'a pas le garantir.

---

(a) C'est pas aucune forme d'attaque personnelle d'ailleurs, je ne fais qu'indiquer pourquoi vos déclarations sont erronées dans le contexte de la pensée critique. Par exemple, le raisonnement suivant est également invalide :

Tous les chiots sont mignons. Cette chose est mignonne. Donc cette chose doit être un chiot.

Le caractère mignon ou non des chiots n'a pas d'importance ici, tout ce que je dis c'est que les deux faits ne mènent pas à la conclusion, parce que les deux premières phrases permettent l'existence de choses mignonnes qui sont pas des chiots.

Cela va dans le sens de votre première déclaration, sans nécessairement imposer la seconde.

Answer 3

Je laisserai toutes les autres réponses se passer d'explications sur les limitations de segment, les architectures exotiques, etc.

N'est-ce pas le simple différence de noms une raison suffisante pour utiliser le bon type pour la bonne chose ?

Si vous stockez une taille, utilisez size_t . Si vous stockez un pointeur, utilisez intptr_t . Une personne lisant votre code saura instantanément que "aha, ceci est une taille de quelque chose, probablement en octets", et "oh, voici une valeur de pointeur stockée comme un entier, pour une raison quelconque".

Sinon, vous pouvez simplement utiliser unsigned long (ou, en ces temps modernes, unsigned long long ) pour tout. La taille n'est pas tout, les noms de types ont une signification qui est utile puisqu'elle aide à décrire le programme.

Answer 4

Il est possible que la taille du plus grand tableau soit plus petite qu'un pointeur. Pensez aux architectures segmentées - les pointeurs peuvent être de 32 bits, mais un seul segment peut être capable d'adresser seulement 64 Ko (par exemple l'ancienne architecture 8086 en mode réel).

Bien que ces derniers ne soient plus couramment utilisés dans les ordinateurs de bureau, la norme C est destinée à prendre en charge même les petites architectures spécialisées. Il existe encore des systèmes embarqués développés avec des CPU de 8 ou 16 bits, par exemple.

Answer 5

J'imagine (et cela vaut pour tous les noms de types) que cela permet de mieux transmettre vos intentions dans le code.

Par exemple, même si unsigned short et wchar_t sont de la même taille sous Windows (je pense), en utilisant wchar_t au lieu de unsigned short montre l'intention de l'utiliser pour stocker un caractère large, plutôt qu'un nombre arbitraire.