[Linux-bruxelles] RE: [Linux-bruxelles] Thème pour lesdéveloppeurs.

[Cabuzel Thierry]

> -----Original Message-----
> From: Stephane Wirtel [mailto:stephane.wirtel at belgacom.net]
> 
> Les problèmes tels que le buffer overflows, sont dûs à des 
> développeurs
> qui pensent que l'OS pourra toujours faire une allocation de 
> 255 bytes.
> Ce qui est faux, donc chaque programmeur doit vérifier son 
> code. Auditer
> le code et vérifier les algorithmes qui semblent complexes sont des
> choses à faire.

Oui, c'est vrai. Mais pourquoi s'occuper de la gestion de la mémoire alors que le but de ton programme n'est pas de gérer la mémoire? Pourquoi vérifier si l'OS fait bien son boulot alors que le but de ton application n'est pas de vérifier que l'OS fait bien son boulot?
Quand tu écris une application de gestion de vidéothèque pour toi à la maison, ton but est d'écrire un prgramme qui vérifie l'allocation de mémoire, qu'on ne peut pas faire de buffer overflow ou d'écrire une application de gestion de vidéothèque?

> Maintenant, si Redhat développe en Python, c'est parce qu'il est plus
> rapide de développer une application en Python, qu'en C ;-) 
> N'oublions
> pas que Python est fait en C.

Oui, et heureusement, mais c'est un code C sur lequel on est sencé pouvoir se reposer les yeux fermés. C'est un code C ou il est censé ne pas avoir possibilitée de buffer overflow, c'est un code C ou il est censé ne pas avoir de fuite mémoire... Et ce code C "parfait" te permet de ne pas te soucier de ce genre de problèmes.

> Concernant les fuites de mémoires, le développeur DOIT 
> checker son code,
> avec des outils adéquats, tels que gdb, ddd, memprof, etc... 
> et tester
> son code dans des cas très rares, mais qui peuvent survenir afin de
> vérifier que celui-ci tient le coup.

Oui, c'est vrai. Mais c'est excessivement contraignant et prend beaucoup de temps. Temps qui n'est pas utilisé à développer réellement ton application. 

> Portabilité ? N'oublions pas que la portabilité des 
> langages tels que
> Java, Python, Perl, et tant d'autres, est dûe à une 
> standardisation des
> API nécessaires à ces langages. Par exemple, la VM de Java 
> est écrite en
> C++ si je ne me trompe pas et c'est cette couche qui produit cette
> portabilité. Le C fait de même, il suffit de voir BSD, GNU/Linux, et
> d'autres systèmes d'exploitation qui sont "portables" sur 
> différentes
> architectures.

Et c'est l'un des reproches que je fais au C, ses API (bibliothèques) sont que trop peu portables à l'exception de stdio.h et quelques autres :( C'est pour cela que dans le code source C de Linux, Java, Python, etc.. on a des IFDEF #Win32, IFDEF #Linux, IFDEF #BSD, IFDEF #386, ... dois-je continuer ? Si tu appelle ca de la portabilitée alors oui le langage C est portable. Pour moi portable veux dire: pas de IFDEF #(os/plateforme/processeur).

> Multi-tache ? Linux est écrit en C, et gère le multi-tache 
> Ã  ce que je
> sache, et l'utilisation des librairies tels que la pthread, ou autres
> permet de faire du multi-threading. Tout comme en python.

Attention ne confond pas. Ce n'est pas parce que ton langage ne supporte pas le multi-tache que tu ne peut pas développer un système multi-tache avec (heureusement, sinon Linux aurais quelques problèmes). Mais le fait de ne pas en disposer complique le travail. J'ai moi même écris durant mes études un bibliothèque pour faire du multi-tache en Pascal avec tout ce qu'il faut. Le résultat est un mélange de Pascal et d'assembleur pour certaines fonctions. C'est faisable, mais pas evident et il est facile de faire des conneries.
Si j'avais pus disposer de structure de langage pour faire du multi-tache en pascal je n'aurais pas perdus à l'époque plus de 40h sur mon projet à écrire cela. Je reviens à une question posée plus haut: tu est la pour écrire ton programme ou écrire les fonctionnalitées que je considère de base pour ton programme ?

> Exceptions ? Je me souviens d'un article où l'on expliquait 
> de manière
> très détaillée la possibilité de créer un gestionnaire 
> d'exceptions pour
> le développement C, je pense qu'il s'agit d'un ancien Login qui date
> d'environ 2 ans.

Oui, comme on met un emplatre sur une fracture. Si le mécanisme n'est pas construit dans le langage, sa structure/son écriture ne sera pas aussi propre et donc aussi lisible. Avec le préprocesseur de macro on peut ecrire avec une syntaxe Pascal en C si on le veux...

> Orienté Objet ? à l'époque cette technique n'existait pas, 
> donc n'a pas

ERREUR !!! L'orienté objet existait avec le langage Simula I crée en 1964, C date de 1971.

A l'époque du C existait:
 * la programmation objet existait (Simula I, 1964)
 * le garbage collector existait (Lisp, 1958) (Smalltalk, 1969)
 * les exceptions existaient (Cobol, 1968 voir moins)

Thierry
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/linux-bruxelles/attachments/20031008/ff002e71/attachment-0002.html>