Caster un int en pointeur

Salutations !

Je code depuis quelques jours une implémentation de plusieurs API pour un nouvel OS.

Deux fonctions de ces API servent à échanger des identifiants de tâches et, pour des raisons historiques certainement, les identifants de tâches sont considérés comme étant des int32_t.

J'ai donc les deux fonctions suivantes à implémenter :

Code:

---

1 2	int32_t getCurrentTaskID(void); // renvoie l'ID de la tache courante wakeup(int32_t ID); // reveille la tache reperee par ID

---

Pour les précédentes implémentations, les OS géraient les ID avec des int32_t (où le "historiques" ci-dessus) mais le nouvel ID utilise lui des TaskHandle qui correspondent à des pointeurs sur void :

Code:

---

typedef void * TaskHandle;

---

Etant sur une architecture 32 bits et supposant donc qu'un pointeur était stocké dans int32_t, j'ai tenté de renvoyer avec getCurrentTaskID() l'adresse de ma variable handle ; avec la fonction wakeup(), je caste l'int32_t en TaskHandle*, je récupère son contenu et je suis arrivé à quelque chose de fonctionnel.

En faisant cela, je me suis rappelé de ce qu'avait dit diogene ces jours-ci.

Question bête : comment faire mieux ? :oops:

Merci d'avance pour vos idées !

L'API de l'OS sur lequel tu veux implémenter ton programme me rappelle qq chose, serait-ce FreeRTOS ?

Ceci étant dit, le mieux est d'après moi que ton interface soit modifiée, pour permettre à la plateforme cible d'accepter un type différent de int32_t pour identifier des taches. Un truc genre :

Code:

---

1 2 3 4 5 6 7 8 9

#ifdef SYSTEM_DONT_JE_CONNAIS_PAS_LE_NOM typedef TaskHandle Taskid; #else typede int32_t Taskid; #endif   Taskid getCurrentTaskID(void); // renvoie l'ID de la tache courante wakeup(Taskid ID);

---

mais bon c'est pas tjs possible, sinon tu serais pas ici à poser la question.

Un autre point de vue c'est d'analyser comment ton OS fonctionne et déterminer s'il y a une chance pour qu'un jour le TaskHandle soit hors limite pour un int32. C'est cochon.

Encore un autre point de vue, c'est de construire une grosse abstraction, avec un tableau en interne qui liste toutes les taches en court et contient les TaskHandle respectifs, et retourner un index sur ce tableau.

Bien vu, il s'agit de FreeRTOS ;)

L'idéal serait effectivement une modification de l'API mais ce n'est pas très facile à faire sans risquer de casser la compatibilité. Surtout que l'API est indépendante d'un éventuelle OS sous-jacent.

En regardant sur le net, j'ai trouvé un type qui pourrait se révéler utile : ptrdiff_t. Il m'a déjà permis de voir que pour mon architecture, int32_t et ptrdiff_t correspondent tous les deux à un signed int. Je peux donc caster comme un cochon sans risque de perdre la partie haute de mon adresse.

L'idée d'un tableau associatif est tentante mais ça risque d'être une vraie usine à gaz. Je cible pour l'occasion des micro-contrôleurs de type Cortex M3, je n'ai pas une mer de de ressources à ma disposition. L'implémentation de l'API étant dépendant de la plateforme, de l'OS, vérifier comme un cochon si un tel cast marche ou pas est a priori plus "intéressant".

Au final, ma question est plus : si int32_t et ptrdiff_t correspondent tous les deux au même type, le cast dans les 2 sens est-il garanti pour donner un résultat correct ?

Normalement, tu devrais te tourner plutôt vers intptr_t ou uintptr_t

n1256 :

Citation:

---

7.18.1.4 Integer types capable of holding object pointers
1 The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:
intptr_t
The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:
uintptr_t
These types are optional.

---

J'ai aussi vu ces 2 types. Ils en parlent dans sur le site que j'ai lié dans mon message précédents, disant que c'était même type "réel" mais que les noms faisaient qu'ils étaient plus parlant dans un cas ou dans l'autre. Connais-tu une différence autre que le nom ? En tout cas, cela confirme que je peux faire mon cast pour la plateforme actuelle, puisque les tailles sont en accord.

D'ailleurs, pourquoi faire une variable signée et une non signée pour faire la même chose ?

ptrdiff_t est le type de la différence entre deux pointeurs qui est déjà nativement un entier défini par la norme qui explique bien comment la différence entre deux pointeurs est faite. Il n'y aura donc de ce fait pas de problèmes spécifiques de cast avec un autre type entier. Mais il n'est pas fait logiquement pour représenter des pointeurs en entiers.

intptr_t ou uintptr_t sont des entiers résultant d'un cast d'un pointeur vers un entier, opération qui est dépendante de l'implémentation. La norme ne dit pas comment cet entier sera obtenu à partir du pointeur et ne garantit en fait qu'une forme de réversibilité du cast. Dans tous les cas, on ne peut faire aucune opération sur ces entiers à part la copie et le cast vers void*.
La norme donne ces types comme optionnels, ce qui signifie aussi qu'il n'est pas obligatoire que les deux soient définis. Il est probable que si ces deux types sont définis, ils aient la même taille en nombre de bits et que même si ces types entiers représentent alors des étendues de nombre différentes, c'est l'opération de cast vers un void* qui en tiendra compte pour rétablir le bon pointeur. Dans ce cas, les deux sont possibles uniquement pour permettre à l'utilisateur une certaine souplesse en fonction de son code (il peut préférer avoir un type signé ou un type non signé).

Personnellement, je m'orienterais sans doute vers intptr_t/uintptr_t quitte à devoir faire explicitement un typedef si il n'est pas déjà défini.

Merci beaucoup pour tes commentaires, je m'en souviendrai le moment où un nouveau portage à risque se présentera. Et je m'en souviendrai aussi pour le reste du temps ^^