On a vu l'extrait de code de cette personne.
Il est clairement mauvais.
On a vu l'extrait de code de cette personne.
Il est clairement mauvais.
On a vu l'extrait de code de cette personne.
Il est clairement mauvais.
http://www.google.fr/search?hl=fr&ie=UTF-8&oe=UTF-8&q=%22Alan+Cox%22&btnG=Recherche+Google&meta > (environ 520000 réponses, contre 6180 pour Steve Balmer)
http://www.google.fr/search?hl=fr&ie=UTF-8&oe=UTF-8&q=%22Alan+Cox%22&btnG=Recherche+Google&meta > (environ 520000 réponses, contre 6180 pour Steve Balmer)
http://www.google.fr/search?hl=fr&ie=UTF-8&oe=UTF-8&q=%22Alan+Cox%22&btnG=Recherche+Google&meta > (environ 520000 réponses, contre 6180 pour Steve Balmer)
On en revient toujours là : à quel prix ? Un code de qualité moyenne ?
On parlait exactement de ça. Il y a 2 choix : un code sûr mais long à
écrire et cher (logiciels industriels), ou un code correct écrit
rapidement mais sujet à failles (logiciels grand public).
On en revient toujours là : à quel prix ? Un code de qualité moyenne ?
On parlait exactement de ça. Il y a 2 choix : un code sûr mais long à
écrire et cher (logiciels industriels), ou un code correct écrit
rapidement mais sujet à failles (logiciels grand public).
On en revient toujours là : à quel prix ? Un code de qualité moyenne ?
On parlait exactement de ça. Il y a 2 choix : un code sûr mais long à
écrire et cher (logiciels industriels), ou un code correct écrit
rapidement mais sujet à failles (logiciels grand public).
C'est trop facile de dire "c'est un logiciel grand public, c'est normal
qu'il y ait tant de failles". Les navigateurs alternatifs montrent que
c'est une très piètre excuse.
C'est trop facile de dire "c'est un logiciel grand public, c'est normal
qu'il y ait tant de failles". Les navigateurs alternatifs montrent que
c'est une très piètre excuse.
C'est trop facile de dire "c'est un logiciel grand public, c'est normal
qu'il y ait tant de failles". Les navigateurs alternatifs montrent que
c'est une très piètre excuse.
Misterjack écrit:Et je parlais de code de qualité industrielle, puisque je répondais à
une remarque sur la qualité du code de Windows(r). Je voulais dire qu'un
code reconnu fiable et maintenable prend beaucoup de temps. Je me
re-cite : "Je parle de faire reconaître un logiciel comme fiable et
maintenable."
MS-Windows, qualité "industrielle" ?
Un logiciel est fiable et maintenable quand il fait ce qu'on lui
demande et qu'il est maintenu. Ce sont des qualités qui s'aquierent
avec l'usage et non pas avec le temps passé à sa préparation.
On en revient toujours là : à quel prix ? Un code de qualité moyenne ?
On parlait exactement de ça. Il y a 2 choix : un code sûr mais long à
écrire et cher (logiciels industriels), ou un code correct écrit
rapidement mais sujet à failles (logiciels grand public).
Non, la qualité d'un programme ne dépend pas de son coût.
Les programmes que j'utilise, pour moi et pour mes serveurs, ont un
coût d'achat nul, ce n'est pas pour celà qu'ils sont de qualité nulle.
Misterjack <stock@mjcie.info> écrit:
Et je parlais de code de qualité industrielle, puisque je répondais à
une remarque sur la qualité du code de Windows(r). Je voulais dire qu'un
code reconnu fiable et maintenable prend beaucoup de temps. Je me
re-cite : "Je parle de faire reconaître un logiciel comme fiable et
maintenable."
MS-Windows, qualité "industrielle" ?
Un logiciel est fiable et maintenable quand il fait ce qu'on lui
demande et qu'il est maintenu. Ce sont des qualités qui s'aquierent
avec l'usage et non pas avec le temps passé à sa préparation.
On en revient toujours là : à quel prix ? Un code de qualité moyenne ?
On parlait exactement de ça. Il y a 2 choix : un code sûr mais long à
écrire et cher (logiciels industriels), ou un code correct écrit
rapidement mais sujet à failles (logiciels grand public).
Non, la qualité d'un programme ne dépend pas de son coût.
Les programmes que j'utilise, pour moi et pour mes serveurs, ont un
coût d'achat nul, ce n'est pas pour celà qu'ils sont de qualité nulle.
Misterjack écrit:Et je parlais de code de qualité industrielle, puisque je répondais à
une remarque sur la qualité du code de Windows(r). Je voulais dire qu'un
code reconnu fiable et maintenable prend beaucoup de temps. Je me
re-cite : "Je parle de faire reconaître un logiciel comme fiable et
maintenable."
MS-Windows, qualité "industrielle" ?
Un logiciel est fiable et maintenable quand il fait ce qu'on lui
demande et qu'il est maintenu. Ce sont des qualités qui s'aquierent
avec l'usage et non pas avec le temps passé à sa préparation.
On en revient toujours là : à quel prix ? Un code de qualité moyenne ?
On parlait exactement de ça. Il y a 2 choix : un code sûr mais long à
écrire et cher (logiciels industriels), ou un code correct écrit
rapidement mais sujet à failles (logiciels grand public).
Non, la qualité d'un programme ne dépend pas de son coût.
Les programmes que j'utilise, pour moi et pour mes serveurs, ont un
coût d'achat nul, ce n'est pas pour celà qu'ils sont de qualité nulle.
Pas étonnant, il s'appelle Steve Ballmer avec deux "l".
Pas étonnant, il s'appelle Steve Ballmer avec deux "l".
Pas étonnant, il s'appelle Steve Ballmer avec deux "l".
Désolé de te contredire, mais j'ai laissé mon code un an sans y
toucher puis l'ai modifié pour tenir compte de nouvelles librairies et
pour ajouter de nouvelles fonctionalités.
Visiblement tu as des problèmes pour écrire du code que tu peux relire
toi même et tu généralises ton problème.
Dans un milieu de production, on ne passe pas des mois à se triturer
le cerveau en équipe avant de coder 1000 lignes. Ça c'est une hérésie.
Vous avez oublié de recopier les indentations.
Variables non initialisées,
ha ?
indentation inexistante,
Après que vous les ayez effacées, c'est normal.
noms de variables absolument pas explicite,
La longueur du nom d'une variable est proportionnelle à sa portée.
non codage de
chaînes répétitives (genre "crypt") en constantes,
C'est déjà des constantes (c'est comme ça que ça s'appelle en C). Vous
pensez obscurcir le code en ajoutant des macros pour un usage limité ?
utilisation très étrange
(et non optimisée) de l'append de l'octet NULL avec strncpy()
(pourquoi copier x si le xeme est mis à NULL ensuite ?)
L'octet NUL (et non pas NULL). Vous ne savez manistestement pas
utiliser strncpy(), ce qui entraine votre étrange remarque. Quand à
l'optimisation en n'affectant pas un octet, c'est ridicule : l'appel à
crypt() plus haut fait du DES. Modifier une bonne habitude de
programmation pour un gain relativement nul montre votre niveau
scolaire.
et, à moins d'un effet de
style très hors de portée d'un débutant (genre je sors de l'école)
qui aurait à maintenir ce code, erreur à if (salt=NULL). Erreur
facilement évitable en affectant les variables à l'envers,
En quoi ?
Il y a certe une erreur, mais,
si vous aviez lu le programme, ce
morceau est sans incidence,
même si, comme ce n'est jamais le cas
sémantiquement ou opérationnellement, salt pouvait NULL. Le fonction
est d'ailleurs sensée planter dans ce cas, ce qu'elle fait plus haut.
Guignol, va.
Mais oui, tu as appris le C à l'école il y a plus de 20 ans et tu te
rappelles encore de tes notes et de ton prof. Tu as fais l'école du
rire ?
Désolé de te contredire, mais j'ai laissé mon code un an sans y
toucher puis l'ai modifié pour tenir compte de nouvelles librairies et
pour ajouter de nouvelles fonctionalités.
Visiblement tu as des problèmes pour écrire du code que tu peux relire
toi même et tu généralises ton problème.
Dans un milieu de production, on ne passe pas des mois à se triturer
le cerveau en équipe avant de coder 1000 lignes. Ça c'est une hérésie.
Vous avez oublié de recopier les indentations.
Variables non initialisées,
ha ?
indentation inexistante,
Après que vous les ayez effacées, c'est normal.
noms de variables absolument pas explicite,
La longueur du nom d'une variable est proportionnelle à sa portée.
non codage de
chaînes répétitives (genre "crypt") en constantes,
C'est déjà des constantes (c'est comme ça que ça s'appelle en C). Vous
pensez obscurcir le code en ajoutant des macros pour un usage limité ?
utilisation très étrange
(et non optimisée) de l'append de l'octet NULL avec strncpy()
(pourquoi copier x si le xeme est mis à NULL ensuite ?)
L'octet NUL (et non pas NULL). Vous ne savez manistestement pas
utiliser strncpy(), ce qui entraine votre étrange remarque. Quand à
l'optimisation en n'affectant pas un octet, c'est ridicule : l'appel à
crypt() plus haut fait du DES. Modifier une bonne habitude de
programmation pour un gain relativement nul montre votre niveau
scolaire.
et, à moins d'un effet de
style très hors de portée d'un débutant (genre je sors de l'école)
qui aurait à maintenir ce code, erreur à if (salt=NULL). Erreur
facilement évitable en affectant les variables à l'envers,
En quoi ?
Il y a certe une erreur, mais,
si vous aviez lu le programme, ce
morceau est sans incidence,
même si, comme ce n'est jamais le cas
sémantiquement ou opérationnellement, salt pouvait NULL. Le fonction
est d'ailleurs sensée planter dans ce cas, ce qu'elle fait plus haut.
Guignol, va.
Mais oui, tu as appris le C à l'école il y a plus de 20 ans et tu te
rappelles encore de tes notes et de ton prof. Tu as fais l'école du
rire ?
Désolé de te contredire, mais j'ai laissé mon code un an sans y
toucher puis l'ai modifié pour tenir compte de nouvelles librairies et
pour ajouter de nouvelles fonctionalités.
Visiblement tu as des problèmes pour écrire du code que tu peux relire
toi même et tu généralises ton problème.
Dans un milieu de production, on ne passe pas des mois à se triturer
le cerveau en équipe avant de coder 1000 lignes. Ça c'est une hérésie.
Vous avez oublié de recopier les indentations.
Variables non initialisées,
ha ?
indentation inexistante,
Après que vous les ayez effacées, c'est normal.
noms de variables absolument pas explicite,
La longueur du nom d'une variable est proportionnelle à sa portée.
non codage de
chaînes répétitives (genre "crypt") en constantes,
C'est déjà des constantes (c'est comme ça que ça s'appelle en C). Vous
pensez obscurcir le code en ajoutant des macros pour un usage limité ?
utilisation très étrange
(et non optimisée) de l'append de l'octet NULL avec strncpy()
(pourquoi copier x si le xeme est mis à NULL ensuite ?)
L'octet NUL (et non pas NULL). Vous ne savez manistestement pas
utiliser strncpy(), ce qui entraine votre étrange remarque. Quand à
l'optimisation en n'affectant pas un octet, c'est ridicule : l'appel à
crypt() plus haut fait du DES. Modifier une bonne habitude de
programmation pour un gain relativement nul montre votre niveau
scolaire.
et, à moins d'un effet de
style très hors de portée d'un débutant (genre je sors de l'école)
qui aurait à maintenir ce code, erreur à if (salt=NULL). Erreur
facilement évitable en affectant les variables à l'envers,
En quoi ?
Il y a certe une erreur, mais,
si vous aviez lu le programme, ce
morceau est sans incidence,
même si, comme ce n'est jamais le cas
sémantiquement ou opérationnellement, salt pouvait NULL. Le fonction
est d'ailleurs sensée planter dans ce cas, ce qu'elle fait plus haut.
Guignol, va.
Mais oui, tu as appris le C à l'école il y a plus de 20 ans et tu te
rappelles encore de tes notes et de ton prof. Tu as fais l'école du
rire ?
Parler du délai avant de publier une faille de sécurité serait donc
hors charte sur fr.comp.securite ?
Parler du délai avant de publier une faille de sécurité serait donc
hors charte sur fr.comp.securite ?
Parler du délai avant de publier une faille de sécurité serait donc
hors charte sur fr.comp.securite ?
Combien de temps avant publication ici ils ont été prévenus ? (pour
pouvoir corriger avant qu'une personne mal intentionnée n'exploite cela)
Combien de temps avant publication ici ils ont été prévenus ? (pour
pouvoir corriger avant qu'une personne mal intentionnée n'exploite cela)
Combien de temps avant publication ici ils ont été prévenus ? (pour
pouvoir corriger avant qu'une personne mal intentionnée n'exploite cela)
AMcD écrit:Bis repetita. Je ne le connais pas. Je ne le prends pas pour un neuneu. Je
réagis vis-à-vis de ses propos. Point. On n'écrit pas des applis de 22k
lignes sans beaucoup de commentaires. C'est inmaintenable par toute autre
personne que celle qui l'a écrit (et encore, faut-il qu'il n'y revienne pas
un an après).
Désolé de te contredire, mais j'ai laissé mon code un an sans y
toucher puis l'ai modifié pour tenir compte de nouvelles librairies et
pour ajouter de nouvelles fonctionalités.
Visiblement tu as des problèmes pour écrire du code que tu peux relire
toi même et tu généralises ton problème.
Et à moins d'avoir une documentation et un cahier de charges
professionnels de plusieurs dizaines de pages (et encore !), on n'écrit pas
des applis professionnelles sans beaucoup de commentaires. C'est une
hérésie.
Dans un milieu de production, on ne passe pas des mois à se triturer
le cerveau en équipe avant de coder 1000 lignes. Ça c'est une hérésie.
AMcD <arnold.mcdonald@free.fr> écrit:
Bis repetita. Je ne le connais pas. Je ne le prends pas pour un neuneu. Je
réagis vis-à-vis de ses propos. Point. On n'écrit pas des applis de 22k
lignes sans beaucoup de commentaires. C'est inmaintenable par toute autre
personne que celle qui l'a écrit (et encore, faut-il qu'il n'y revienne pas
un an après).
Désolé de te contredire, mais j'ai laissé mon code un an sans y
toucher puis l'ai modifié pour tenir compte de nouvelles librairies et
pour ajouter de nouvelles fonctionalités.
Visiblement tu as des problèmes pour écrire du code que tu peux relire
toi même et tu généralises ton problème.
Et à moins d'avoir une documentation et un cahier de charges
professionnels de plusieurs dizaines de pages (et encore !), on n'écrit pas
des applis professionnelles sans beaucoup de commentaires. C'est une
hérésie.
Dans un milieu de production, on ne passe pas des mois à se triturer
le cerveau en équipe avant de coder 1000 lignes. Ça c'est une hérésie.
AMcD écrit:Bis repetita. Je ne le connais pas. Je ne le prends pas pour un neuneu. Je
réagis vis-à-vis de ses propos. Point. On n'écrit pas des applis de 22k
lignes sans beaucoup de commentaires. C'est inmaintenable par toute autre
personne que celle qui l'a écrit (et encore, faut-il qu'il n'y revienne pas
un an après).
Désolé de te contredire, mais j'ai laissé mon code un an sans y
toucher puis l'ai modifié pour tenir compte de nouvelles librairies et
pour ajouter de nouvelles fonctionalités.
Visiblement tu as des problèmes pour écrire du code que tu peux relire
toi même et tu généralises ton problème.
Et à moins d'avoir une documentation et un cahier de charges
professionnels de plusieurs dizaines de pages (et encore !), on n'écrit pas
des applis professionnelles sans beaucoup de commentaires. C'est une
hérésie.
Dans un milieu de production, on ne passe pas des mois à se triturer
le cerveau en équipe avant de coder 1000 lignes. Ça c'est une hérésie.
