Linux: pourquoi le sig atomic t est-il typé en int?

C99 sig_atomic_t se conforme seulement à une définition très faible de "l'atomicité", parce que C99 n'a pas de concept de concurrence, seulement interruptibilité. (C2011 ajoute un modèle de concurrence, et avec lui le _Atomic types qui font des garanties plus fortes; cependant, AFAIK sig_atomic_t est inchangé depuis sa raison d'être est toujours en communication avec les manipulateurs de signaux, pas à travers les threads.)

C'est tout C99 dit à propos de sig_atomic_t:

(§7.14 <signal.h>, paragraphe 2) le type défini est sig_atomic_t, qui est le type entier (éventuellement qualifié de volatile) d'un objet auquel on peut accéder en tant qu'entité atomique, même en présence d'interruptions asynchrones. (§7.14!--4-->, paragraphe 2)

(§7.14p5) si le signal [a] se produit autrement que par suite de l'appel du abort ou raise fonction, le comportement n'est pas défini si le gestionnaire de signal se réfère à un objet avec une durée de stockage statique autre que par affectation d'une valeur à un objet déclaré que volatile sig_atomic_t.

(§7.18.3 limites des autres types entiers, paragraphe 3) Si sig_atomic_t (voir 7.14) est défini comme un type entier signé, la valeur de SIG_ATOMIC_MIN ne doit pas être supérieur -127 et la valeur de SIG_ATOMIC_MAX ne doit pas être inférieur à 127; sinon, sig_atomic_t est défini comme un type entier non signé, et la valeur de SIG_ATOMIC_MIN est 0 et la valeur de SIG_ATOMIC_MAX ne doit pas être inférieur à 255.

Le terme "atomique entité " n'est défini nulle part dans la norme. La traduction de normes-ese, le intention est que le CPU peut mettre à jour complètement une variable de type sig_atomic_t dans la mémoire ("statique de la durée de stockage") avec une instruction machine. Ainsi, dans la machine abstraite C99 sans concurrence et avec précision interruptible, il est impossible pour un manipulateur de signal d'observer une variable de type sig_atomic_t à mi - chemin d'une mise à jour. Le §7.18.3P3 licences de langues ce type doit être as petit que char si nécessaire. Veuillez absence totale de toute langue relative à la cohérence entre processeurs.

il y a de vrais CPU qui nécessitent plus d'une instruction pour écrire une valeur plus grande que char à la mémoire. Il y a aussi de vrais CPU qui nécessitent plus d'une instruction pour écrire des valeurs plus petit qu'un mot machine (souvent, mais pas nécessairement le même que int) à la mémoire. La langue dans la bibliothèque GNU C manuel est maintenant inexactes. Il représente un désir de la part des Auteurs originaux d'éliminer ce qu'ils voyaient comme licence inutile pour les implémentations C de faire des trucs bizarres qui ont rendu la vie plus difficile pour les programmeurs d'application. Malheureusement, c'est cette même licence qui permet d'avoir du C sur de vraies machines. Il y a au moins un port Linux intégré (à L'AVR) pour lequel aucun int nor les pointeurs peuvent être écrits en mémoire en une seule instruction. (Les gens travaillent à faire le manuel est plus précis, voir par exemple http://sourceware.org/ml/libc-alpha/2012-02/msg00651.html-- sig_atomic_t semble avoir été oubliée dans un, cependant.)