Discussion :

[Marc.Samuro]

Bonjour au forum,

passionné de C depuis plus de 10 ans et ayant l'habitude des gros programmes de plus de 50,000 lignes, cela m'a toujours embêté d'avoir autant de difficultés pour trouver et corriger les bugs, le C ne vérifiant ni les indices de tableaux, ni les pointeurs.

J'ai envisagé de passer au C++ ou au C#, mais ni l'un ni l'autre ne me satisfont vraiment : le C++ ne vérifie pas plus les indices et les pointeurs que le C, et le C# ne génère pas du vrai code assembleur et en plus est lourd et lent avec son garbage collector.

Bref, une seule solution restait : créer mon propre langage qui ressemblerait très fort au C et en garderait la vitesse que nous apprécions tous, mais en même temps le transformer pour qu'il ne soit plus possible qu'une partie du code écrive en mémoire où il ne peut pas ...

Je l'ai baptisé le Safe-C, je pense que cela résume bien ce que c'est.

Pendant tout 2010 j'ai écris les spécifications du langage ainsi qu'un compilateur Safe-C pour Windows; maintenant en 2011 je suis en train d'écrire les librairies.

C'est un vrai langage où on peut faire tout ce qu'on peut faire aussi en C, mais si l'un des indices de tableau déborde ou qu'un pointeur écrit où il ne peut pas, vous aurez tout de suite une erreur qui vous indique où dans le code source il y a problème, d'où énormément de temps gagné en développement.

Si quelqu'un ici a envie de participer à cette aventure (il y a encore beaucoup à faire : écrire des librairies, des tutorials, proposer des modifs) il est le bienvenu Il faut qu'il connaisse bien le C parce que le Safe-C en est très proche.

J'ai mis un premier tutorial pour débutants en informatique sur ce site provisoire : http://newchatrooms.dyndns.dk:12000/...IAL/start.html

Je suis en train d'écrire des librairies faciles à utiliser pour IPV4 et IPV6, d'autres suivront ..

Pour me contacter c'est marcsamu@hotmail.com

Si cela rencontre du succès on pourra peut-être ouvrir une rubrique ici sur le forum ..

[gl]

le C++ ne vérifie pas plus les indices et les pointeurs que le C

As-tu entendu parlé de std::vector (et autres containers standards), std::string, smart pointer, référence, etc. ?

Même si le C++ n'est pas parfait à ce niveau là, dire qu'il n'apporte rien de plus que le C c'est quand même assez gros.


Sinon concernant ton langage, quelques questions suite à ta présentation :

• Tu dis que les indices et pointeurs sont vérifiés par le langage, mais comment ? A quel moment (compile time ou run time) ? Que se passe-t-il précisément en cas d'erreur ? Jusqu'à quel point le comportement peut-il être configurer ?
• Pourquoi ne pas avoir choisi une politique où les tableaux gèrent leur taille et sont capables de se redimensionner lorsque nécessaire (particulièrement en ce qui concerne les chaînes de caractères) ?
• Es-tu capables de t'interfacer avec d'autres langages (notamment le C) ? Si oui, comment ?

[Mat.M]

Je suis totalement d'accord avec Gl les conteneurs du C++ donnent entièrement satisfaction pas besoin d'être un expert du C++ pour les utiliser
Et puis il y a Boost aussi ( intégrée à Visual Studio 2010 )

et le C# ne génère pas du vrai code assembleur et en plus est lourd et lent avec son garbage collector.

là aussi je suis d'accord ( ce n'est pas le sujet ) J'ai une certaine aversion pour tout ce qui est .NET

[Marc.Samuro]

réponse à ql:

Q1:
c'est clair que les librairies string, vecteur, etc.. du C++ apportent une sécurité, mais elle est limitée à ces type de données (string ou vecteur).

En Safe-C je voulais une sécurité à 100%, même pour les simples tableaux, même pour les printf, les passages de paramètres, pointeurs, etc ... il n'y a pas de faille.

Il est cependant possible de créer des pointeurs non-vérifiés comme en C en utilisant les pragma "#begin unsafe" et "#end unsafe". C'est nécessaire pour interfacer avec Windows.

Q2:
Les pointeurs sont vérifiés à l'exécution pour un mécanisme de tombstone (voir wikipedia).
C'est vrai que c'est plus lent que des pointeurs classiques, mais :
- cela offre une sécurité à 100% : cela vérifie les pointeurs non valides, les double-free, tous les cas sont prévus.
- c'est scalable (donc ne ralentit pas pour les gros programmes contrairement aux langages qui utilisent un garbage collector).
- on utilise beaucoup moins les pointeurs en Safe-C que dans les langages qui ont des classes, donc un léger ralentissement ne se remarque pas.

Q3:
en cas d'erreur le programme se plante à l'endroit de l'erreur. Donc il n'écrase pas de données plus loin et ne peut pas écraser la pile. On a directement l'endroit de l'erreur et on peut corriger, donc c'est mieux qu'en C. En tant que programmeur C le mécanisme d'exception du C++ me semble trop lourd et bon, le but ici est de n'avoir aucune exception.

Q4:
Le safe-C reprend la plupart des éléments du C, et les strings dynamiques n'en font pas partie.

Q5:
pour le moment je peux m'interfacer avec des DLL windows, j'en suis à la version 1 du compilateur.

réponse à LLB:
Q1: l'interopérabilité est, disons, faisable. Actuellement je suis en train de reprendre toutes mes anciennes librairies source C et de les adapter, cela va quand même assez vite.

Q2: je ne connais pas D mais c'est OO je pense ?

Q3: le compilateur Safe-C génère du bon vieux code machine 32-bit pour Windows (processeur Intel/Amd) (je n'ai pas inclus les instructions SSE parce que tous le monde ne les a pas). Le compilateur est déjà prévu pour générer du 64-bit, ce sera pour plus tard.

Q4: les performances sont aussi bonnes qu'en C. Les vérifications d'indice de tableau ne génèrent que 2 instructions assembleur en plus, cela ne se remarque même pas.

Q5: non pas encore de debugger, je suis à la version 1 là.


Bon vous avez tous l'air de tirer à boulets rouge dessus, c'est vrai que ce langage ne propose rien de révolutionnaire. C'est un dérivé du C qui propose plus de sécurité et en profite pour améliorer 2 ou 3 choses. Le langage reste petit et simple comme le C, il n'y a pas de quoi brandir les fourches et de tout brûler hein .

- Peut-on utiliser des outils existants (IDE, débogueurs...) avec votre langage ?

ah des outils existants ! oui on peut, en fait j'utilise le debugger de visual C pour le moment. Mais j'ai écris une librairie d'exception qui redirige le vecteur d'exception de windows, donc en cas de plantage ça m'affiche directement l'endroit dans le source, c'est pratique. Je n'ai pas encore d'IDE, je travaille en Dos là.

Le but du Safe-C est qu'il ne soit pas possible qu'une partie d'un programme écrase les données d'une autre partie du programme en dehors des règles du langage : les indices de tableau sont vérifiés, les pointeurs passent par des tombstone, les strings ont un byte 0 optionnel et non obligatoire comme en C, les fonctions à nombre variable de paramètres créent un tableau sur la pile avec les paramètres variables et seul l'adresse du tableau est passée.

Il y a beaucoup de vérifications à la compilation : tout doit être initialisé, même les tableaux (il y a d'ailleurs une commande 'clear' pour effacer une variable), le compilateur vérifie aussi que le string "%s%d" d'un printf correspond aux arguments si celui-ci est constant, ce qui évite d'avoir des erreurs à l'exécution. Bref, le Safe-C reprend tous les éléments du C et les rend sûrs.

Il y a 2 ou 3 choses nouvelles seulement : un type "opaque" qui est la même chose que "struct" mais les champs du struct ne sont pas visible dans d'autres fichiers. (encapsulation de données); des packages génériques aussi (l'équivalent des templates du C mais simplifiés à l'extrème; tout se passe à la compilation, cela remplace en fait les macros du C).

[LLB]

Bon vous avez tous l'air de tirer à boulets rouge dessus, c'est vrai que ce langage ne propose rien de révolutionnaire.

Oui, et c'est le problème. C'est très dur de populariser un nouveau langage. En général, un langage ne marche que s'il est vraiment novateur (et se démarque du reste) ou s'il est poussé par une entreprise (ou université, centre de recherche).
Si quelqu'un veut utiliser ce nouveau langage, quelle garantie a-t-il qu'il sera toujours maintenu dans 5 ou 10 ans ?

Après, il ne faut pas prendre les critiques mal, ça permet de mieux se rendre compte des qualités ou défauts du langage. Pour ma part, ça doit être le 10e langage que je croise qui souhaite corriger les défauts du C. Personnellement, pour avoir travaillé professionnellement sur la conception et l'implémentation de nouveaux langages, je sais à quel point c'est difficile d'en populariser un. Écrire un compilateur qui marche n'est pas le plus dur.

Q2: je ne connais pas D mais c'est OO je pense ?

Oui (un peu comme en C++). Voir ici
Disons que ça reprend des idées du C++, en enlevant un certain nombre de problèmes (car ils n'ont pas gardé la compatibilité avec le C). Un peu moins de puissance qu'en C++ (templates plus simples, par exemple), mais c'est plus sûr et plus simple.

Q1: l'interopérabilité est, disons, faisable. Actuellement je suis en train de reprendre toutes mes anciennes librairies source C et de les adapter, cela va quand même assez vite.

Il faut réécrire le code ? Si on veut utiliser DirectX, OpenGL ou toutes les autres bibliothèques populaires, ça représente beaucoup de travail ?

Q3: le compilateur Safe-C génère du bon vieux code machine 32-bit pour Windows (processeur Intel/Amd) (je n'ai pas inclus les instructions SSE parce que tous le monde ne les a pas).

Tandis que le JIT de C# est capable d'utiliser les SSE quand c'est disponible (c'est un avantage du JIT). Générer du code efficace n'est pas simple, il y a énormément d'optimisations à faire. Même si C# n'a pas de performances optimales (parce qu'il fait de l'introspection, garde les infos de type à l'exécution, parce que le JIT ne peut pas prendre 10s pour optimiser...), ça m'intéresse de voir des benchmarks avec votre compilateur.

Cela m'intrigue : pourquoi ne pas utiliser un backend existant ? Pourquoi ne pas utiliser par exemple LLVM ? Vous avez vraiment envie de réécrire la génération de code pour chaque architecture à gérer ? La portabilité est quand même l'un des gros avantages du C, il ne faudrait pas l'oublier.

Les vérifications d'indice de tableau ne génèrent que 2 instructions assembleur en plus, cela ne se remarque même pas.

Les compilateurs existants (comme en C#) sont capables de ne pas faire la vérification d'indice dans de nombreux cas (grâce à une analyse statique du code).

En tant que programmeur C le mécanisme d'exception du C++ me semble trop lourd et bon, le but ici est de n'avoir aucune exception.

Lourd à quel niveau ? Je trouve que la gestion d'erreurs est bien plus lourde à faire correctement en C qu'en C++.

En Safe-C je voulais une sécurité à 100%, même pour les simples tableaux

Que se passe-t-il si on accède hors d'un tableau (avec un indice variable) ? Ne pensez-vous pas que lancer une exception serait la bonne chose à faire dans ce cas ?

Il y a beaucoup de vérifications à la compilation

Les compilateurs C sont déjà capables de vérifier le format d'un printf quand il est connu ou vérifier que les variables sont initialisées (dans les cas simples).

c'est clair que les librairies string, vecteur, etc.. du C++ apportent une sécurité, mais elle est limitée à ces type de données (string ou vecteur).

Les références sont aussi plus sûres que les pointeurs.

[gl]

Bon vous avez tous l'air de tirer à boulets rouge dessus, c'est vrai que ce langage ne propose rien de révolutionnaire. C'est un dérivé du C qui propose plus de sécurité et en profite pour améliorer 2 ou 3 choses. Le langage reste petit et simple comme le C, il n'y a pas de quoi brandir les fourches et de tout brûler hein .

Non, ma but n'est pas de tirer à boulet rouge. Je cherche simplement à savoir ce que propose ton langage et s'il est susceptible de m'intéresser.
Au risque de paraître un peu brutal, s'il ne m'apporte rien, il n'y a aucune chance que j'y passe du temps dessus (je n'ai déjà pas assez de temps pour me consacrer à tout les langages, bibliothèques, articles, etc. qui m'intéressent)

Les pointeurs sont vérifiés à l'exécution pour un mécanisme de tombstone (voir wikipedia).
C'est vrai que c'est plus lent que des pointeurs classiques, mais :
- cela offre une sécurité à 100% : cela vérifie les pointeurs non valides, les double-free, tous les cas sont prévus.
- c'est scalable (donc ne ralentit pas pour les gros programmes contrairement aux langages qui utilisent un garbage collector).

Et concernant les accès hors borne du tableau ? Également à l'exécution ?
Pourquoi ne pas chercher à vérifier ce qui peut l'être à la compilation ?

- on utilise beaucoup moins les pointeurs en Safe-C que dans les langages qui ont des classes, donc un léger ralentissement ne se remarque pas.

Euh ! Quel est le rapport entre le faite d'avoir des classes et la densité de pointeurs dans un programme ?

en cas d'erreur le programme se plante à l'endroit de l'erreur. Donc il n'écrase pas de données plus loin et ne peut pas écraser la pile. On a directement l'endroit de l'erreur et on peut corriger, donc c'est mieux qu'en C. En tant que programmeur C le mécanisme d'exception du C++ me semble trop lourd et bon, le but ici est de n'avoir aucune exception.

Donc un problème implique forcément un crash du programme. Il n'y a pas moyen d'intercepter les erreurs et de les traiter différemment (ce que permettent les exceptions) ?

Le safe-C reprend la plupart des éléments du C, et les strings dynamiques n'en font pas partie.

std::string c'est du C++ pas du C. Il n'y a actuellement pas de type string en C.

pour le moment je peux m'interfacer avec des DLL windows, j'en suis à la version 1 du compilateur.

Ce qui ne veut pas dire grand chose.

Peux-tu passer tes tableaux et des pointeurs managés aux APIs systèmes ? Sais-tu recevoir des pointeurs en retour de ces mêmes APIs ? Dans ce cas deviennent-ils safe ? Comment gères-tu le fait de ne pas forcément avoir de \0 terminal dans tes chaînes lorsque tu appelles une fonction qui attends la présence de ce \0 ? Es-tu capables d'appeler des fonctions variadic ? Etc ...

l'interopérabilité est, disons, faisable. Actuellement je suis en train de reprendre toutes mes anciennes librairies source C et de les adapter, cela va quand même assez vite.

Qu'appelles-tu "adapter les librairies C" ? Tu ne penses quand même pas à les réécrire en safe-C une par une. Même si unitairement le travail n'est peut être pas énorme (et encore ?), je ne pense pas que porter plusieurs milliers de bibliothèques soit vraiment ce que l'on puisse appeler interopérabilité.

je ne connais pas D mais c'est OO je pense ?

Non, c'est multi-paradigme (tout comme le C++). L'OO n'est qu'un des paradigmes supportés.

le compilateur Safe-C génère du bon vieux code machine 32-bit pour Windows (processeur Intel/Amd) (je n'ai pas inclus les instructions SSE parce que tous le monde ne les a pas). Le compilateur est déjà prévu pour générer du 64-bit, ce sera pour plus tard.

Ne trouves-tu pas contradictoire de te plaindre des performances de certains langages et en même temps ne pas supporter certaines instructions des processeurs qui permettent d'en gagner ? Surtout lorsque les compilateurs pour ces langages sont eux capables de gérer ces instructions.

les performances sont aussi bonnes qu'en C. Les vérifications d'indice de tableau ne génèrent que 2 instructions assembleur en plus, cela ne se remarque même pas.

La question n'est pas tant le coût des instructions supplémentaires pour la gestions des bornes de tableau (bien que dans certains cas, il est possible de ne pas le faire si la vérification est faite à la compilation) mais de savoir si ton compilateur safe-C optimise aussi bien le code que le ferais un compilateur C.

non pas encore de debugger, je suis à la version 1 là.

Le problème est qu'il est difficile actuellement de "vendre" un nouveau langage s'il n'a pas un minimum d'écosystème autour.

Il y a beaucoup de vérifications à la compilation :

Ce qui est, ama, une bonne chose.

tout doit être initialisé, même les tableaux (il y a d'ailleurs une commande 'clear' pour effacer une variable)

Dans les exemples que tu donnes, tout n'est pas initialisé à la création. Par contre tout semble l'être avant la première utilisation. Est-ce bien de cela que tu parles ?

Certains compilateurs C (par exemple gcc) sont capables de réaliser (enfin dans une certaines mesures, certaines constructions complexes posent problèmes) ce type de tests.

le compilateur vérifie aussi que le string "%s%d" d'un printf correspond aux arguments si celui-ci est constant, ce qui évite d'avoir des erreurs à l'exécution.

Là encore gcc (et probablement d'autres compilateurs) effectuent cette vérification pour les fonctions variadic de la bibliothèque standard (dont printf).

Il y a 2 ou 3 choses nouvelles seulement : un type "opaque" qui est la même chose que "struct" mais les champs du struct ne sont pas visible dans d'autres fichiers.

Et ce que celà via à la place des structures ou en plus ?
Quel est l'avantage par rapport à la construction classique en C qui consiste à définir la structure uniquement dans le fichier source qui implémente les fonctions de celle-ci et de simplement fournir une déclaration incomplète dans le header ?

des packages génériques aussi (l'équivalent des templates du C mais simplifiés à l'extrème; tout se passe à la compilation, cela remplace en fait les macros du C).

Peux-tu en dire plus (je n'ai rien trouver à ce sujet dans la page que tu as fourni).

Que peut-on faire avec ? Comment est-ce gérer ?

[Marc.Samuro]

Q: Il faut réécrire le code ? Si on veut utiliser DirectX, OpenGL ou toutes les autres bibliothèques populaires, ça représente beaucoup de travail ?

R: il faut ré-écrire des interface pour chacune des libraries oui, par exemple actuellement j'appelle des DLL Windows comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#begin unsafe
 
struct WSADATA
{
  uint2  wVersion;
  uint2  wHighVersion;
  char   szDescription[256+1];
  char   szSystemStatus[128+1];
  uint2  iMaxSockets;
  uint2  iMaxUdpDg;
  char   *VendorInfo;
}
 
[extern "ws2_32.dll"]
int WSAStartup (uint version, WSADATA *data);
 
#end unsafe
 
....
 
 
int init_socket_library ()
{
  WSADATA  wsaData;
 
#begin unsafe
    if (WSAStartup (0x0202, &wsaData) != 0)   // version 2.2
#end unsafe
    {
      return TCP_DRIVER_PROBLEM;
    }
 
...

Bref, il faut ré-écrire les include files de Windows pour le langage, mais je suppose que c'est pareil pour tout nouveau langage.

----------------------------------------------------------------------

Q: Tandis que le JIT de C# est capable d'utiliser les SSE quand c'est disponible (c'est un avantage du JIT). Générer du code efficace n'est pas simple, il y a énormément d'optimisations à faire. Même si C# n'a pas de performances optimales (parce qu'il fait de l'introspection, garde les infos de type à l'exécution, parce que le JIT ne peut pas prendre 10s pour optimiser...), ça m'intéresse de voir des benchmarks avec votre compilateur

Cela m'intrigue : pourquoi ne pas utiliser un backend existant ? Pourquoi ne pas utiliser par exemple LLVM ? Vous avez vraiment envie de réécrire la génération de code pour chaque architecture à gérer ? La portabilité est quand même l'un des gros avantages du C, il ne faudrait pas l'oublier..

R: il ne faut pas confondre le langage et le compilateur. Bon ici j'ai écris un compilateur pour windows, j'ai essayé d'optimiser au mieux le code généré mais je suis persuadé qu'il y a des spécialistes qui font cela encore mieux que moi.

D'autres personnes peuvent tout à fait écrire leur compilateur, j'ai rédigé des spécifications techniques très précises qui décrivent le langage en détails afin que les programmes soient tous portables (voir le lien tout en bas sur la page de début du site).

----------------------------------------------------------------------

Q: Que se passe-t-il si on accède hors d'un tableau (avec un indice variable) ? Ne pensez-vous pas que lancer une exception serait la bonne chose à faire dans ce cas ?

R: En C il n'y a pas d'exceptions, j'ai écris des très gros programmes professionellement et je n'en ai jamais eu besoin, donc pourquoi en ajouter ? Une erreur comme un dépassement d'indice est une erreur grave qui ne devrait
jamais arriver et qui demande un arrêt du process. Vouloir rattrapper cela par un handler d'exception qui redémarre le programme est une option qu'on peut aussi implémenter en redémarrant le process.

Beaucoup de langages sont trop gros et complexes, je préfère rester minimaliste, comme le C.

----------------------------------------------------------------------

Q: Et concernant les accès hors borne du tableau ? Également à l'exécution ?
Pourquoi ne pas chercher à vérifier ce qui peut l'être à la compilation ?

R: le compilateur vérifie les indices de tableau (et aussi de slices de tableau, =tranches) à la compilation si les indices sont des expressions constantes.

----------------------------------------------------------------------

Q: Quel est le rapport entre le faite d'avoir des classes et la densité de pointeurs dans un programme ?

R: je précise mon idée : en fait dans les langages OO, quand vous créez une grande variable (classe ou tableau), vous la créez sur le heap. En C (et Safe-C) vous pouvez créer une grande variable structure ou tableau sur la pile, ce qui ne nécessite aucune indirection de pointeur pour y accéder (c'est mov eax,[ebp]offset pour charger un champ d'une struct déclarée comme variable locale) alors qu'en OO vous avez toujours un pointeur sur chaque classe (même si ça ne s'appelle pas pointeur). Il y a donc beaucoup plus de "pointeurs" (ou indirections) en langage OO qu'en C.

Disons pour parler clairement, les langages OO créent une multitute d'objets sur le heap (pour chaque classe), le C et Safe-C n'en font que si on utilise explicitement des pointeurs.

----------------------------------------------------------------------

Q: Peux-tu passer tes tableaux et des pointeurs managés aux APIs systèmes ? Sais-tu recevoir des pointeurs en retour de ces mêmes APIs ? Dans ce cas deviennent-ils safe ?

R: bien sûr on sait passer des tableaux aux API. Pour passer l'addresse d'une variable à un API on utilise l'opérateur & comme en C qui permet de prendre l'adresse d'une variable et dont le résultat est un pointeur (non-managé), exactement comme en C. Evidemment le truc c'est que l'opérateur & n'est autorisé qu'à l'intérieur d'une section #begin unsafe .... #end unsafe, donc généralement dans une librairie. Les utilisateurs ne sont pas censés
utilisés ces sections unsafe ou en tout cas le moins possible, parce qu'avec elles on programme exactement comme en C, sans sécurité.

Je précise que les pointeurs ne sont pas "managés", les objets ne bougent pas, il n'y pas de garbage collection et il faut faire ses free soi-même (il y un opérateur "new" très riche pour créer même des struct et tableau dynamiques, et une commande free).

----------------------------------------------------------------------

Q: Comment gères-tu le fait de ne pas forcément avoir de \0 terminal dans tes chaînes lorsque tu appelles une fonction qui attends la présence de ce \0 ?

R: il faut recopier la chaine et ajouter un zéro, pareil qu'en C#, pour tous les APIs qui ont besoin d'un PSTR. J'ai constaté qu'il n'y en a pas tant que cela en pratique dans l'API windows, et aucun pour des fonctions qui doivent être performantes comme read & write.

//----------------------------------------------------------------------------

Q: Es-tu capables d'appeler des fonctions variadic ?

R: oui mais elle ne sont pas passées comme en C. Les addresses et tailles des arguments variables sont tous rassemblés et mis dans un tableau et l'adresse du tableau est passé comme 1 paramètre. Je pense que le C# fait comme cela aussi. L'utilisateur peut donc créer sans problème des fonctions à nombre de paramètres variables comme printf, fprintf, etc .. avec sécurité totale.

//----------------------------------------------------------------------------

Q: Qu'appelles-tu "adapter les librairies C" ?

R: j'ai une collection de librairies source C que je soigne depuis 10 ans, pour tcpip, traitement d'image, ... Je pense qu'en 3 mois j'aurai tout adapté en Safe-C pour que je puisse continuer à programmer dans ce langage. Maintenant n'importe qui peut créer ses propres librairies, c'est comme en C, on peut partir de zéro.

//----------------------------------------------------------------------------

Q: Ne trouves-tu pas contradictoire de te plaindre des performances de certains langages et en même temps ne pas supporter certaines instructions des processeurs qui permettent d'en gagner ? Surtout lorsque les compilateurs pour ces langages sont eux capables de gérer ces instructions.

R: j'écris des programmes qui sont distribués sur internet et qui donc doivent tourner sur toutes les versions de Windows et tous les CPU. Actuellement pour mes librairies je n'utilise que des API à partir de Windows 2000 et aucune instruction SSE. Maintenant il est possible que je propose un petit moteur 3D avec des instructions SSE2 inline (c'est pratique pour multipler 4 float en 1 instruction mais alors avec avertissement que ce n'est pas pour toutes les machines.

//----------------------------------------------------------------------------

Q: Dans les exemples que tu donnes, tout n'est pas initialisé à la création. Par contre tout semble l'être avant la première utilisation. Est-ce bien de cela que tu parles ?

R: oui, toutes les variables doivent être initialisées à la première utilisation. Le compilateur suit le flot des instructions et vérifie cela. C'est très important pour la sécurité. Initialiser un champ d'un struct ne suffit pas pour que le struct soit considéré comme initialisé, il faut soit un "clear", soit une assignation à la variable entière. Le langage a un très bon support pour les constantes (simple, tableau, struct, jagged) ainsi que les aggregates, afin de rendre simple ces initialisations.

Un exemple:

date = {day => 1, month => 1, year => 2011};

//----------------------------------------------------------------------------

Q: Et ce que celà via à la place des structures ou en plus ?
Quel est l'avantage par rapport à la construction classique en C qui consiste à définir la structure uniquement dans le fichier source qui implémente les fonctions de celle-ci et de simplement fournir une déclaration incomplète dans le header ?

R: un type opaque est défini comme ceci dans le .h :

struct MON_TYPE;

Dans le .c correspondant, il doit y avoir la déclaration complète :

struct MON_TYPE;
{
int a, b, c;
}

Donc évidemment si un autre fichier "importe" le .h il n'a pas accès aux champs.

Je signale qu'il n'y a pas "d'#include" comme en C, c'est plus un import de libraries comme en C#, ce qui a pas mal d'avantages : l'ordre des imports n'a pas d'importance, il ne faut pas inclure une librairie avant une autre.

A signaler aussi : le compilateur 'trouve' automatiquement les fichiers à inclure. Si vous faites :

// main.c

use sys/mylib;


Il va chercher un fichier mylib.h dans le répertoire ./sys et le compiler, ensuite il va voir s'il n'y a pas un mylib.c correspondant dans le même répertoire. Bref, plus la peine d'écrire des makefile, le compilateur trouve les fichiers tout seul en suivant les "use" dans chaque fichier.

//----------------------------------------------------------------------------

Q: Peux-tu en dire plus (je n'ai rien trouver à ce sujet dans la page que tu as fourni).
Que peut-on faire avec ? Comment est-ce gérer ?

R:
Les packages génériques c'est une idée que j'ai repris du langage Ada en simplifiant.

En gros : un générique consiste à écrire un morceau de code en "paramétrant" un ou plusieurs "type" que vous ne spécifiez pas. Le compilateur va compiler ce générique en le vérifiant syntaxiquement, mais il ne va pas en générer de code assembleur.

Une fois écrit, vous pouvez "instancier" ce package en spécifiant des types à la place des paramètres. Lors d'une commande d'instantiation le compilateur va prendre une copie du package générique, remplacer les types paramètres par vos types et générer du code. Tout cela se passe à la compilation. ça ressemble à une macro en C sauf que le package générique est vérifié syntaxiquement. On peut aussi imbriquer un package générique dans un autre comme on imbrique une macro dans une autre.

C'est une forme très simple de générique, destinée par exemple à écrire des routines de tri, d'arbres binaires qui ont des noeuds qui portent des données, bref, plutôt des algorithmes qui resteront dans une librarie.

Après avoir étudié l'utilisation pratique des génériques par 99% des programmeurs, je n'ai créé qu'un seul genre de type générique, privé, qui permet les assignations uniquement, c'est beaucoup plus simple que dans les autres langages, mais aussi plus compréhensible.

Il y a un exemple de générique pour bubble-sort au chapitre 9. Generics (le manuel de référence est le lien tout en bas sur la page de début du site).

//----------------------------------------------------------------------------

[LLB]

- Qu'en est-il de l'interopérabilité avec le C ?
- Que pensez-vous de D ?
- Quel est votre modèle de compilation ? Générez-vous du code C, appelez-vous un back-end existant (comme LLVM) ou générez-vous directement le code binaire ?
- Qu'en est-il des performances (vous semblez attaquer C#, mais c'est bien plus optimisé que ce que vous semblez croire) et de la portabilité ?
- Peut-on utiliser des outils existants (IDE, débogueurs...) avec votre langage ?

J'ai envisagé de passer au C++ ou au C#, mais ni l'un ni l'autre ne me satisfont vraiment : le C++ ne vérifie pas plus les indices et les pointeurs que le C, et le C# ne génère pas du vrai code assembleur et en plus est lourd et lent avec son garbage collector.

C++ vérifie les accès aux vecteurs, strings, etc. Du C++ correctement utilisé vérifie beaucoup de choses et est beaucoup plus sûr que le C. C# génère du vrai code natif à la volée (ce qui présente beaucoup d'avantages).

Il existe déjà beaucoup de dérivés du C, la plupart d'entre eux ayant essayé de corriger les problèmes de sûreté. N'y en a-t-il vraiment pas un qui vous satisfasse ? Créer un énième langage, ne proposant quasiment rien de nouveau, me semble totalement voué à l'échec.

[TropMDR]

Bonjour

Je dois tout d'abord dire que je suis assez admiratif devant la quantité de boulot produit (même si je n'ai pas regardé en détail): des specs et un compilo complet, chapeau.

Ceci étant dit, il me semble que le processus est passablement absurde...

Déjà, tu pars d'une constatation très légèrement réductrice...

J'ai envisagé de passer au C++ ou au C#, mais ni l'un ni l'autre ne me satisfont vraiment : le C++ ne vérifie pas plus les indices et les pointeurs que le C, et le C# ne génère pas du vrai code assembleur et en plus est lourd et lent avec son garbage collector.

Il y a quand même plus que deux langages autre que le C... On a l'impression que tu as choisi les deux seuls avec "C" dans le nom. Et comme il a été dit, le C++ ne fait pas plus que le C quand tu utilises le sous ensemble du C++ qui est là pour rester "compatible" avec le C. Et puis alors le coup du "le C# a un GC, donc il est super lent", on a l'impression que tu n'as pas regardé l'évolution de l'informatique depuis les années 80 ! Ca fait longtemps qu'on n'a plus un facteur 50 entre les langages "non compilés" et les "compilés" hein. On a fait quelques progrès depuis le lisp.

Ensuite tu as fait le choix de tout réécrire. Quand l'objectif est d'avoir un résultat "sûr" et rapide, ça me semble un choix risqué. Pour faire un compilo de qualité, il faut quand même un paquet d'optimisations qui risque facilement d'être buggué. Est ce que tu as une élimination des sous expressions communes, une propagation des constantes, un inliner, une bonne allocation de registre, etc etc? Parce que si tu n'as pas un compilo au poil, ce n'est pas parce que ton langage est un presque C proche de la machine que le résultat sera compétitif par rapport à un C# JITé. Et si tu as un compilo au poil, sans préjugé de tes talents de programmeur, il a quand même de bonne chance de se retrouver bugué, surtout si c'est un de tes premiers. Quelqu'un a suggéré un backend LLVM, ce qui me semble une très bonne idée. Surtout que vu que c'est supporté par Apple, il y a peu de chances que ça disparaisse dans un futur proche. On a un peu l'impression que tu t'es dis "je vais écrire un compilo" et que tu as foncé tête baissée, sans vraiment regarder autour, ce qui ne présage rien de bon. Pourrais tu détailler un peu plus la techno utiliser pour ton compilo, décrire un peu les langages intermédiaires, les optims, et ce genre de choses?

Ensuite, dans tous tes posts, tu parles de "sécurité à 100%". Avoir un programme qui crash instantanément, c'est clairement mieux qu'une corruption de mémoire. Mais il y a quand même un long chemin avant la "sécurité à 100%"!

Et ce qui est un peu triste, c'est qu'on a vraiment l'impression que tu n'as pas du tout regardé ce qui se faisait en matière de C "safe". Sinon tu serais sans doute tombé sur Cyclone par exemple (http://cyclone.thelanguage.org/wiki/...20to%20Cyclone), qui est ce que tu as fait, mais en beaucoup mieux (nettement plus proche du C, et beaucoup plus sûr que ce que tu as). Je ne vois rien dans ton Safe-C qui soit mieux que leur approche, mais plein de choses nettement moins bien. Peux tu nous donner une comparaison entre ton langage et Cyclone, pour qu'on voit s'il présente le moindre intéret par rapport à ça ?

Bref, pour résumer: il me semble que la première qualité d'un informaticien est la paresse. Ne pas réinventer la roue pour un oui ou pour un nom. Et il me semble que ton approche est à l'anti-thèse absolue de cette vision !

[jabbounet]

je viens de lire rapidement ce post, et j'ai une petite question.

personnellement quand on me parle de sûreté de fonctionnement ou de langage sécurisé j'ai tendance a penser à ADA.

Comment safe-c se démarque t'il par rapport a ce langage?