XChangeProperty pour une propriété atom sur un système où Atom est 64 bits

Le protocole X11 définit un atome comme un entier de 32 bits, mais sur mon système, le type Atom est un typedef pour unsigned long, qui est un entier de 64 bits. Le manuel de Xlib indique que les types de propriété ont une taille maximale de 32 bits. Il semble y avoir un conflit ici. Je peux penser à trois solutions possibles.

  1. Si Xlib traite les propriétés de type XA_ATOM comme un cas particulier, alors vous pouvez simplement passer 32 pour 'format' et un tableau d'atomes pour 'data'. Cela semble impur et hackish, et je doute fortement que ce soit correct.

  2. Le manuel pour Xlib semble être ancien. Comme Atom a une longueur de 64 bits sur mon système, devrais-je passer 64 pour le paramètre 'format' même si 64 n'est pas listé comme valeur autorisée?

  3. Plutôt qu'un tableau d'atomes, dois-je passer un tableau de valeurs uint32_t pour le paramètre 'data'? Cela semble être probablement la bonne solution pour moi, mais ce n'est pas ce qu'ils ont fait dans certaines sources que j'ai recherchées qui utilisent XChangeProperty, comme SDL.

SDL semble utiliser la solution 1 lors de la définition de la propriété _NET_WM_WINDOW_TYPE, mais je suppose que cela peut être un bogue. Sur les systèmes avec peu d'ordre d'octets endian (LSB en premier), cela semble fonctionner si la propriété n'a qu'un seul élément.

Quelqu'un d'autre a-t-il rencontré ce problème? Toute aide est appréciée.

3
Ce que fait SDL est correct. Le format spécifie le nombre de bits utilisés sur le serveur, et non le nombre de bits utilisés dans l'interface Xlib. Vous utilisez toujours un tableau de 'long' avec le format 32 n'importe quoi et ils sont traduits correctement en 32 bits avant d'être envoyés au serveur. Les clients 32 et 64 bits peuvent être connectés au même serveur et doivent échanger des informations. Le format est donc la taille côté serveur.
ajouté l'auteur John Meacham, source

1 Réponses

Pour les routines de propriété, vous voulez toujours passer un tableau de 'long', 'court' ou 'char'. Ceci est toujours vrai indépendamment de la largeur de bit réelle. Donc, même si votre long ou atome est de 64 bits, il sera traduit en 32 bits dans les coulisses.

Le format est le nombre de bits côté serveur utilisés, et non le côté client. Donc, pour le format 8, vous devez passer un tableau char, pour le format 16, vous utilisez toujours un tableau court et pour le format 32, vous utilisez toujours un tableau long. Ceci est complètement indépendant des longueurs réelles de courte ou longue sur une machine donnée. Les valeurs 32 bits telles que Atom ou Window sont toujours dans un 'long'.

Cela peut sembler étrange, mais c'est pour une bonne raison, la norme C ne garantit pas qu'il existe des types qui ont exactement les mêmes largeurs que sur le serveur. Par exemple, une machine sans type 16 bits natif. Cependant, un 'short' est garanti avoir au moins 16 bits et un long est garanti avoir au moins 32 bits. Donc, en faisant de l'API client en termes de «court» et «long», vous pouvez écrire du code portable et toujours avoir de la place pour l'identifiant X complet dans le type C.

4
ajouté