Pourquoi POSIX contredit-il les normes ISO C

Voir http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/socket.h.html

( http://pubs.opengroup.org/onlinepubs/9699919799 est issu du numéro 7 – de 2013 et toujours le même!)

sockaddr_storage est destiné à être transtypé vers d’autres types de structure, mais cela contredit les règles de crénelage des normes ANSI et ISO C, autant que je sache. (Les objects ne sont pas accessibles via des pointeurs sur des types incompatibles, à l’exception du fait que tout est accessible via les 3 types de caractères et que la structure et son premier membre sont interchangeables.)

Je sais que cette pratique de travailler avec des sockets existait bien avant la normalisation de C, mais POSIX est censé être conforme à la norme ISO C et en réalité, cela contredit les normes de son manuel. (Même dans les nouvelles versions de POSIX.)

Pourquoi l’ont-ils fait comme ça en premier lieu? Pourquoi ne l’ont-ils pas changé?

    Les règles de ssortingcte aliasing dans la norme contraignent le code utilisateur et non le code d’implémentation. Étant donné que les en-têtes et les bibliothèques POSIX font partie de la mise en œuvre, il n’y a pas de conflit réel entre POSIX et le standard C.

    Dans une plate-forme open-source, et en particulier sous Linux où la bibliothèque C et le compilateur sont développés par différentes équipes, cela rend la vie difficile aux développeurs, mais c’est leur préoccupation, pas la vôtre. Par exemple, les implémenteurs pourraient:

    • évitez d’exposer le conflit potentiel entre les normes (c’est-à-dire, désactivez les optimisations de repliement de spectre ssortingct);
    • admettez que leur implémentation n’est pas conforme à POSIX (et notez qu’il n’y a par exemple aucune dissortingbution Linux certifiée POSIX);
    • fournir des installations pour s’assurer que les installations potentiellement en conflit ne sont pas réellement en conflit Du sharepoint vue de la norme C, ce serait une extension.

    Cette dernière option est la façon dont les équipes gcc et glibc travaillent pour résoudre le problème sockaddr; voir https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255

    En fait, je ne pense pas qu’il y ait violation de la règle de pseudonyme ssortingcte ici. Oui, vous appelez une fonction dans un type différent, mais qui a dit qu’elle doit être accessible via un pointeur de ce type?

    Les implémentations de protocole connaissent le type approprié de la structure. Ainsi, lorsqu’elles accèdent à la structure, elles la reconvertissent en type approprié. La conversion ici n’est utilisée que pour passer le pointeur d’une routine à une autre, mais le type converti n’est pas utilisé pour accéder aux données.