Discussion :

[Bill Fassinou]

Le premier brouillon de la prochaine révision du standard C, le C2x, est publié
et met l'accent sur la compatibilité du langage

A l'indice TIOBE de novembre 2018, le langage C plane toujours dans le top 3 en occupant la deuxième place juste derrière Java et devant le C++. La popularité du langage n'est donc plus à démontrer. Le comité de normalisation du langage, le WG14, travaille activement sur la prochaine révision du standard C (ISO / IEC 9899). On parle de « C2x », où le "x" représente le chiffre de l'année dans laquelle cette nouvelle norme apparaîtra. L'ensemble de la procédure est régie par la Charte C2x qui décrit et corrige le type d'ajouts et d'améliorations qui seront disponible dans le C2x.

Bien que le comité ne soit pas obligé de commencer à réviser la norme actuelle, il se passe beaucoup de choses qui peuvent ou influencent directement le C. Les exemples en sont l'évolution des langages de programmation de type C (C ++, Java et C#), la menace croissante pour la sécurité sur Internet, la prise de conscience croissante des vulnérabilités des langages de programmation, le ralentissement des progrès de la loi de Moore conduisant à un besoin croissant d'exploiter un parallélisme accru et la mise à jour des normes dans des domaines connexes tels que l’arithmétique en virgule flottante.

Le Comité s’est donc efforcé d’améliorer la portabilité tout en maintenant la définition de certaines caractéristiques de C dépendant de la machine. Il a tenté d'intégrer de nouvelles idées précieuses sans perturber la structure et le tissu de base du langage. Il a essayé de développer un langage clair et cohérent sans invalider les programmes existants. Le premier brouillon contenant les modifications apportées jusqu'ici lors de la réunion d'octobre 2018 du comité à Pittsburgh vient d'être publié.

La plupart des modifications approuvées jusqu'à présent pour C2x n'impliquent pas l'ajout de nouvelles fonctionnalités, mais plutôt clarifient et affinent le comportement de C dans différentes implémentations en ce qui concerne le C ++. L'accent mis sur le raffinement va dans le sens de l'évolution des révisions précédentes du C11 et plus récemment du C17. Voici quelques changements acceptés jusqu'à présent pour le C2x :

• une clarification du mot clé restrict utilisé pour informer le compilateur qu'un objet donné en mémoire n'est accessible que par ce pointeur, à titre d'optimisation N2260 ;
• harmonisation static_assert avec C ++ N2265 ;
• meilleures définitions du comportement des syndicats DR 499 ;
• formats d'évaluation des points flottants N2186 ;
• etc.

Quelques modifications ont été aussi votées dans le C2x avec une période de 6 mois pour les éventuels commentaires ou objections en attendant la prochaine réunion du comité en avril 2019 à Londres :

• exigences d'alignement pour les fonctions de gestion de la mémoire N2293 ;
• facilitez la définition des types entiers étendus, N2303 ;
• ajouter des types entiers larges ou bignum ;
• ajoutez des interfaces génériques de type pour les fonctions de chaîne à la bibliothèque C, N2068 ;
• ajouter des constantes générales pour tous les types de données ;
• étendre le concept des expressions constantes de nombre entier ;
• etc.

La feuille de route actuelle pour C2x prévoit au moins deux ans de plus pour que les propositions soit introduites. Le WG14 vise une norme du langage révisée d'ici la fin de l'année 2021, ensuite s'ensuivra la publication en 2022. Les révisions précédentes de la norme C ont ajoutées des fonctionnalités facilitant la gestion de la mémoire, notamment la fonctionnalité de vérification des limites. Cependant, l'une des propositions pour le C2x est de rendre obsolètes ou de supprimer les API Annexe K, car leurs implémentations sur le terrain sont en grande partie incomplètes, non conformes et non portables. Les propositions alternatives incluent le remplacement de ces API par des systèmes tiers de vérification des limites tels que Valgrind ou Intel Pointer Checker, l’affinement du modèle de mémoire ou l’ajout de nouvelles méthodes de vérification des limites pour les objets de mémoire.

Source : Charte C2x

Et vous ?

Que pensez-vous de ces modifications en cours pour la prochaine révision du standard C ?

Voir aussi

GCC 8.1 est disponible, la nouvelle version majeure du compilateur libre vient avec un support expérimental de C++2a et d'autres fonctionnalités

GCC : la version 7.3 du compilateur libre est disponible avec des correctifs pour la vulnérabilité Spectre pour les dispositifs x86 et powerpc

GCC 8.1, la nouvelle version majeure du compilateur libre sera disponible début 2018 : un aperçu des fonctionnalités et changements attendus

Le projet GNU annonce l'intégration du langage de programmation D dans GCC, qui vient s'ajouter au C, C++, Objective-C, Java, Ada et Fortran

[Markand]

Quasiment aucun compilateur a implémenté le C11. Donc j'ose pas imaginer le C2x.

[Matt_Houston]

• meilleures définitions du comportement des syndicats DR 499 ;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
union U {
  struct {
    char B1;
    char B2;
    char B3;
    char B4;
  };
  int word;
} u;

Incroyable, merci pour ça. J'ai du code qui dépend du comportement de GCC sur ce point..

Quasiment aucun compilateur a implémenté le C11. Donc j'ose pas imaginer le C2x.

[Médinoc]

meilleures définitions du comportement des syndicats DR 499;

Il est rare que je ne comprenne pas une trouduction à partir du français, mais là j'étais au point mort et il a vraiment fallu que je regarde l'anglais pour comprendre.

ajoutez des interfaces génériques de type pour les fonctions de chaîne à la bibliothèque C, N2068 ;

Rétablir la const-correctness des fonctions *chr? Hell yes!

Reste à savoir si Visual C++ implémentera ça d'ici 2040.

Edit: Pour les histoires d'alignement de malloc(), je suis surpris que tant d'implémentations reposent sur le weak-alignment (c'est-à-dire pouvoir allouer des petits espaces sans leur donner l'alignement des grands). Vue toute la gestion à faire autour des allocations, je me serais attendu à ce que pratiquement toutes les implémentations utilisent le strong-alignment (genre, chaque allocation alignée sur 16 octets) parce que c'est plus facile à coder, surtout dans une implémentation "liste chaînée" du tas (dans laquelle on n'est plus forcément à 15 octets près pour chaque allocation)...

[Invité]

Quasiment aucun compilateur a implémenté le C11. Donc j'ose pas imaginer le C2x.

N'importe quoi. Il ne faut pas prendre visual c++ pour une généralité.

Visual C++ doesn't support most of the changes in ISO C11
https://docs.microsoft.com/en-us/cpp...e?view=vs-2017

GCC 4.9 Changes: “ISO C11 support is now at a similar level of completeness to ISO C99 support: substantially complete
https://gcc.gnu.org/wiki/C11Status

Clang strives to both conform to current language standards (up to C11 and C++11) and also to implement many widely-used extensions
https://clang.llvm.org/compatibility.html

[Sve@r]

Bonjour

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
union U {
  struct {
    char B1;
    char B2;
    char B3;
    char B4;
  };
  int word;
} u;

Incroyable, merci pour ça. J'ai du code qui dépend du comportement de GCC sur ce point..

Y aurait-il plusieurs façons de comprendre ce truc ? Parce que pour moi ça me semble assez clair quoi (excepté qu'il manque le nom de la structure mais il doit s'agir d'un simple oubli de transcription). Toutefois j'aurais mis "word" en long pour être certain qu'il fasse bien 4 octets.

Ceci dit, peut-être que remplacer la structure par un tableau de char serait plus simple à écrire et tout aussi simple à utiliser...

[Matt_Houston]

(excepté qu'il manque le nom de la structure mais il doit s'agir d'un simple oubli de transcription)

Il s'agit d'un anonymous struct C11 et c'est le cœur du problème, décrit plus en détails par ce ticket sur SO : https://stackoverflow.com/questions/...ctly-described .

Y aurait-il plusieurs façons de comprendre ce truc ?

C'est cela qui est fou. Lis la DR d'où j'ai tiré cet exemple. Le compilateur IBM pour AIX considère cela comme équivalent à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
union U {
  char B1;
  char B2;
  char B3;
  char B4;
  int word;
} u;

Autrement dit B1, B2, B3 et B4 partagent la même adresse et le struct anonyme qui les englobe est pour ainsi dire ignoré.

Ça ne m'était même pas venu à l'esprit qu'on pouvait interpréter ce point de la norme (bien mal rédigé, il est vrai) différemment de ce que le comité a confirmé - les champs ne se chevauchent pas - mais force est de constater que même dans le cadre le plus formel on n'est jamais à l'abri d'une mésentente due aux préconceptions des uns et des autres.

En attendant de devoir peut-être réécrire mon code, je suis bon pour ajouter quelques static_assert pour me prémunir d'éventuelles déconvenues.

Toutefois j'aurais mis "word" en long pour être certain qu'il fasse bien 4 octets.

Pour ce problème c'est sans importance, on aurait pu écrire n'importe quel type. Dans le cas général, autant recourir à stdint.h / inttypes.h lorsqu'il s'agit d'en être certain.

[grim7reaper]

Pour ceux que ça intéressent, j’avais posté un lien vers un article de blog qui contient plus d’info dans cette autre discussion.