Il s'agit d'une erreur d'entier signé/non-signé pour allocation d'un tampon mémoire, qui peut-être exploitée, selon X-Force, découvreur du bug, sur les plate-formes WIN32 mais pas (pour l'instant ?) sur *n*x (NdM: il semblerait qu'on ait une erreur de segmentation du processus apache concerné si on a un Unix 32 bits et peut être plus embétant en 64 bits).
Note du modérateur: J'ai supprimmé le patch qui était inclus dans la news, vous pouvez le trouver sur le premier lien mais l'annonce d'apache indique qu'il ne corrige pas vraiment le problème.
Aller plus loin
- La SA de X-force (5 clics)
- L'annonce d'apache (4 clics)
- CVS log d'OpenBSD (4 clics)
# Ça concerne aussi Apache 2.x
Posté par Anonyme . Évalué à 10.
Il est intéressant de lire le fil complet de discussion :
http://online.securityfocus.com/archive/1/277324/2002-06-14/2002-06(...)
et une réponse de X-Force
http://online.securityfocus.com/archive/1/277326/2002-06-14/2002-06(...)
# Pas seulement 1.x
Posté par Flyounet (site web personnel) . Évalué à 10.
Le Full Advisory (http://httpd.apache.org/info/security_bulletin_20020617.txt(...)) indique que la 2.0 ne semble pas concernée pour l'execution de code malicieux.
# Précisions
Posté par Gruik Man . Évalué à 10.
Pour ce qui est de l'exploitabilité sur UNIX en 32 bits ou en 64 bits, d'apprès ISS:
Le fait qu'Apache soit exploitable sous windows, étant due, d'après eux, au fait que les pointeurs de gestion d'exception sont stockés sur le stack.
[^] # Re: Précisions
Posté par Aza . Évalué à 10.
C'etait pas pasbillpasgates qui se vantait que le design de windows etait mieux parcequ'il n'etait pas sensible aux bug du double free de la zlib ?
[^] # Re: Précisions
Posté par PLuG . Évalué à 10.
Mais cette fois-ci ce n'est pas un "double-free" ...
Ce n'est pas non plus un probleme avec la gestion mémoire de l'os. Le design de la gestion mémoire est peut-etre TOP (d'apres pbpg au moins), il n'en reste pas moins que d'autres morceaux ont quelques inconvénients ...
[^] # Re: Précisions
Posté par TSelek . Évalué à 10.
De toute façon l'architecture d'Apache est basé sur Unix, on a beau faire un portage windows, c'est sur un Unix que ça tournera le mieux.
Les exceptions sous Windows, ce ne sont pas les trucs qui font beep-beep-beep à l'infini quand l'OS est planté et qu'on bouge la souris ? Ou qui cachent le curseur au bout d'un certain temp ? Enfin bref, dire que Windows est mieux designé c'est se moquer des galeres de ses users.
[^] # Re: Précisions
Posté par Dugland Bob . Évalué à -8.
Les poste du styles : "oui, jes suis d'accord avec toi" ça sert à rien.
[^] # Re: Précisions
Posté par TSelek . Évalué à -7.
C'est pas dans le sens "oui je suis d'accord" qu'il aurait pu poster ici, mais dans le sens "oui j'avais tord..."
Pour être honnête, il me semble qu'il dort à cette heure ci.
[^] # Re: Précisions
Posté par pasBill pasGates . Évalué à 4.
Ca veut pas dire que tout dans l'OS est comme ca.
[^] # Re: Précisions
Posté par TSelek . Évalué à -1.
[^] # Re: Précisions
Posté par Victor Vuillard . Évalué à 7.
[^] # Re: Précisions
Posté par Fabimaru (site web personnel) . Évalué à 2.
Euh, c'est pas plutot des exceptions suite auquelles le systeme recherche un handler dans la pile (genre exception C++), et qui pourraient etre declenchees par la fonction "RaiseException" ?
Moi aussi, je peux dire que les "seg faults", c'est du au fait que linux gere mal les segments memoires...
[^] # Re: Précisions
Posté par TSelek . Évalué à 2.
Raisons : traps H/W ou S/W, interrupts H/W ou S/W, asserts S/W (là sens habituellement utilisé ici).
Le pb des windows, c'est que la gestion des exceptions est elle même sujette à exceptions... Le bouzin est irrecupérable, reboot...
[^] # Re: Précisions
Posté par Ben (site web personnel) . Évalué à 10.
Il y a segfault si ton programme tape volontairement (pas toi, mais le prog) dans un segment non autorisé. Le segfault est justement le résultat d'une bonne gestion par le noyau qui a repéré une intrusion du programme là ou il ne doit pas foutre le nez.
Qd y a un segfault et si le prog ne gère pas les exceptions (pas de setjmp (C) ou de try (C++) alors le noyau tue le process et continue tranquillement son job (sauf si le prog n'est pas en user-space), au lieu de te foutre un écran bleu pour te demander de rebooter de toute façons.
Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie
[^] # Re: Précisions
Posté par VERMEEREN Sebastien . Évalué à 6.
[^] # Re: Précisions
Posté par TSelek . Évalué à 1.
[^] # Re: Précisions
Posté par Gaël Le Mignot . Évalué à 8.
Sinon, parler de 'segment' mémoire c'est un peu abusif puisque Linux n'utilise que la pagination, pas la segmentation.
[^] # Re: Précisions
Posté par Moby-Dik . Évalué à 1.
[^] # Re: Précisions
Posté par Miod in the middle . Évalué à 5.
[^] # Re: Précisions
Posté par Moby-Dik . Évalué à -1.
[^] # Re: Précisions
Posté par Fabimaru (site web personnel) . Évalué à 6.
Pas vu de Beep Beep depuis NT et 2000. A chaque troll "problemes sous Windows" on fait reference aux horreurs des windows 95/98/ME... Windows n'est plus un systeme globalement instable.
[^] # Re: Précisions
Posté par VERMEEREN Sebastien . Évalué à -2.
ok -1 :)
[^] # Re: Précisions
Posté par Robert Palmer (site web personnel) . Évalué à 10.
C'était peut-être vrai pour Apache 1.x, mais Apache 2 a été clairement conçu pour être performant sur les plateformes non-Unix et notamment Windows : http://httpd.apache.org/docs-2.0/new_features_2_0.html(...)
Maintenant, en ce qui concerne Windows, autant il était facile de s'en moquer à l'époque des 95, 98 et Me, autant il faut reconnaître que Win 2000 et XP sont techniquements très bon et qu'il faut argumenter un peu plus que dire « ce ne sont pas les trucs qui font beep-beep-beep à l'infini... » pour convaincre les gens.
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Précisions
Posté par VERMEEREN Sebastien . Évalué à 1.
- aspect exterieur : la pluspart des gens font confiance à ce qu'il voit. Lorsque tu veux vendre un produit l'aspect est essentiel tout est une question de but.
- delais de réaction : parfois proportionnel au bug, mais je pense que tous les bugs soumis ont un jour trouvé leur solution. C'est le minimum.
- Support / doc : msdn.microsoft.com . Il n'y a aucun equivalent sur linux. Je ne connais pas un site sous linux qui t'explique comment faire un drag and drop, ecrire un driver et donne les bugs et leurs solutions.
- Politique : ca c'est un avis personnel à chacun de juger....
Par contre ce qui est clair c'est que microsoft est la pour faire de l'argent avec leur produit. Je te rejoins sur l'ethique morale :
Est on libre de tout faire pour vendre son produit ?
Par contre je pense que techniquement les programmeurs de chez microsoft sont loin d'etre des zeros, mais qu'ils sont peut etre parfois eux aussi gêné par le service marketing.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Précisions
Posté par Paul Andre . Évalué à 1.
perso, je trouve que msdn n'est vraiment pas pratique, il y est tres dur de trouver de l'information concise et pertinente (c'est surement un manque d'habitude de ma part, mais lorsque je cherche la solution sur google, je trouve beaucoup des personnes qui ont les memes problemes "techniques" non triviaux que moi)
d'autre part comme tout les editeurs closed source que je connaisse, ils ne donnent ni la complexite, ni l'occupation memoire necessaire a leurs algos, ce qui nous force a realiser des tests pour prevoir le fonctionnement de nos programmes.
# Rien à voir
Posté par Infernal Quack (site web personnel) . Évalué à -4.
hop -1
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# BugTraq vs. SecurityFocus
Posté par Foxy (site web personnel) . Évalué à 10.
Je crois que l'auteur de la news n'a pas dû tout comprendre :
- BugTraq existe toujours et est la plus importante mailing-liste sur la sécurité informatique sur le Net.
- SecurityFocus est un gros site Web US spécialisé en sécurité. Les serveurs de SecurityFocus gérent la ML BugTraq et archivent les messages et alertes de sécurité de BugTraq.
Donc avant de faire des affirmations pareilles, faut se renseigner ;-)
[^] # Re: BugTraq vs. SecurityFocus
Posté par Mathieu Dessus (site web personnel) . Évalué à 10.
C'est dommage que cette mailling-list soit passé sous le controle d'une société.
[^] # Re: BugTraq vs. SecurityFocus
Posté par Gruik Man . Évalué à 10.
[^] # Re: BugTraq vs. SecurityFocus
Posté par spim . Évalué à 10.
Non aleph1 ne modere plus bugtraq, il a ete remplace par David Ahmad depuis le 15 Octobre 2001.
De plus je me permet d'affiner le fait qu'il a ete CO-fondateur de securityfocus :)
[^] # Re: BugTraq vs. SecurityFocus
Posté par Gruik Man . Évalué à 5.
autantau temps pour moi, c'est vrai.Mais à part ça, j'ai dit qu'il était fondateur, et pas qu'il était LE fondateur - donc, on est d'accord :)
# c'est qd même un faiceau de preuves convergeant
Posté par Dugland Bob . Évalué à -10.
Et il y toujours cette croute dure de développeurs pour défendre leur langage à la con.
C'est rigolot l'absense de cognition chez certains.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par TSelek . Évalué à 10.
Qu'est ce que tu voulais qu'on fasse ? Qu'on euthanasie K&R à leur naissance ? Laisse les vivre bordel ! Ce n'est qu'un overflow, c'est quand même pas la fin du monde ! Si il fallait se mobiliser pour toutes les imperfections du monde comme tu le fais sur les langages "à la con", pfou...
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Dugland Bob . Évalué à -9.
C'est presque toujours des pointeurs explicites qui se barrent en vrille (le plus souvent des buffer overflow).
Se langage, il est chiant à compiler, chiant à optimiser, il rend parano les développeur (obligés de passer des outils pour vérifier la mémoire au lieu de vérifier le fonctionnement) et il rend l'informatique instable.
Tout ça à cause d'une bande d'encroutés qui veut pas changer de métode de travail, ça vaut le coup de critiquer les boites douteuse qd on fait pareil !
Il serait peut-être temps que les développeurs se concentrent sur leur métier plutôt que sur la mémoire. Surtout dans le cadre d'Apache, c'est pas simple, il y a des algos en jeu, des problèmes de puissance, des protocoles de communication et les développeur sont obligés de ce concentrer sur la mémoire.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par TSelek . Évalué à -4.
Tu ne peux pas ne pas avoir entendu parler des méthodes formelles ? Ca marche ? Bof. Enfin si, dans les confs.
Et si on avait du code parfait, plus de hackers non plus.
Ton point de vue est juste, fondé. Mais académique ! Des fois, on aime bien être crade, y'a des codes dans le coin qui le sont bien gruik, et la chasse aux overflows c'est rigolo non ? Tu as pensé à la NSA hein ? Comment ils vont faire avec des OS parfaits ?
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par PLuG . Évalué à 10.
<je marche dedans>
bien sur, avec caml il n'y a pas de failles...,
d'ailleur il n'y a pas de soft non plus :-)
</je marche dedans>
<je pietine meme>
si apache avait ete ecrit en java, il n'y aurait
pas de probleme non plus, personne ne l'utiliserait (IIS serait plus rapide)
</je pietine meme>
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par let antibarbie = xp <- xp - 1 . Évalué à -2.
Ben pourquoi nos grands chercheurs de l'INRIA se cassent le cul a développer des langages magnifiques (bon ok le terme est un peu exagéré), si c'est pour que les gens continuent a développer en C/C++... non non c'est mal(tm) de faire que du C.. et pi un bon algo et des bonnes structures avec un bon niveau d'abstraction, ca peut souvent faire aussi bien -avec un developpement plus rapide et moins buggé- qu'un bout de code écrit en C.
évidemment dans tous les cas, faut que les développeurs soient paranos... et arrêtent de coder comme des porcs :-)
non non y'a pas que Java dans la vie ... et pis le bytecode Caml est (a peu près) compatible Java !
[^] # Je marche dedans moi aussi :))
Posté par Moby-Dik . Évalué à -4.
Ca fait une belle jambe, pour un serveur Web ;)
nos grands chercheurs de l'INRIA se cassent le cul a développer des langages magnifiques (bon ok le terme est un peu exagéré)
C'est surtout pour "grands chercheurs" que le terme est exagéré, à mon avis :)
et pi un bon algo et des bonnes structures avec un bon niveau d'abstraction
C'est possible en C, et encore plus en C++.
et pis le bytecode Caml est (a peu près) compatible Java
Ben, c'est cool, les sources C sont compatibles avec les compilateurs C. Que demande le peuple ?
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Euclide (site web personnel) . Évalué à 10.
donc poursuit ta logique, et recode apache en c++
Quand tu auras fini apache, tu pourras recoder le kernel linux en c++ aussi
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
Franchement, autant utiliser un serveur web fait avec un vrai langage :
http://libre.act-europe.fr/aws/(...)
Quelque chose me dit qu'il doit pas trop avoir de bugs ? :)
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Moby-Dik . Évalué à 3.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Nicolas Roard (site web personnel) . Évalué à -2.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Miod in the middle . Évalué à 10.
Oui, des langages de type C (ou C++, guère meilleur sur ce point de vue) permettent d'écrire facilement (et surtout sans s'en rendre compte) du code non fiable. Cela oblige les programmeurs à se montrer rigoureux, mais quand mien même ils le sont, l'erreur est humaine et tôt ou tard leur code finit par être erroné.
Non, recoder Apache en un autre langage n'est pas réaliste. Ne serait-ce parce que c'est un logiciel complexe, et que l'on ne transpose pas l'expérience et la connaissance de son fonctionnement qu'en ont ses développeurs vers un autre langage en peu de temps.
L'avenir est probablement d'écrire un énième logiciel de serveur web, mais cette fois-ci dans un langage moderne et adapté à ce genre d'application, permettant aux développeurs de se concentrer sur les vrais problèmes à résoudre (performance, scalabilité, mise à disposition du contenu d'un site) plutôt que sur les problèmes liés au système (gestion de la mémoire, des ressources système, des divers processus et/ou thread lancés, etc).
Simplement, une telle chose n'est pas près d'arriver, principalement parce que le monde informatique, et plus particulièrement le monde du logiciel libre, est particulièrement conservateur quant aux méthodes («on a toujours codé en C», «malloc() c'est plus rapide qu'autre chose», «de toute façon pour coder sous un système POSIX seul le C est adapté», etc).
C'est pourquoi ceci ne se produira pas sans un changement des mentalités des programmeurs... et tant que de tels propos seront considérés comme troll, il restera un long chemin à parcourir.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Dugland Bob . Évalué à -10.
Petite précision pour ceux qui ne le sauraient pas : malloc() est bien généralement plus lent qu'une allocation dans un langage moderne.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par TSelek . Évalué à 10.
La différence entre la théorie et la pratique, c'est qu'en pratique on fait tout pour que ça marche.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Dugland Bob . Évalué à -5.
Le cas classique où on touche à l'allocation dans les langages de haut niveau est la réutilisation d'objets, rien de plus.
[^] # Alors pourquoi mes fournisseurs ne me proposent que C et pas Eiffel ?
Posté par TSelek . Évalué à 9.
Et les VM, faut les coder les VM. Elles ne sont pas petites à caser, et il n'y a pas que les mainframes, les serveurs et les desktops dans la vie !
Un exercice de reflexion : que peut-on utiliser comme langage sur une carte à puce ? C'est pousser le bouchon à l'extrème certes, mais les petits systèmes sont les plus nombreux c'en est même un pléonasme.
Dans la vraie vie, on repose sur les outils qui nous sont fournis avec chacune des plateformes, et le plus souvent c'est C ou C/C++, parfois Java (JavaCard). Mais un fournisseur de SOC/ASIC proposer un toolset avec Eiffel dedans, jamais vu...
[^] # Re: Alors pourquoi mes fournisseurs ne me proposent que C et pas Eiffel ?
Posté par CMO (site web personnel) . Évalué à 2.
Chez SLB / Sema tout l'applicatif est ecrit avec Java. Le bas niveau (IO) est fait en assembleur.
[^] # Re: Alors pourquoi mes fournisseurs ne me proposent que C et pas Eiffel ?
Posté par Dugland Bob . Évalué à 5.
D'autre part si l'innovation doit venir des université, qu'elle en vienne, ça me dérange pas. Elle pourrait même venir de MS (avec les risques que ça comporte) avec le CLR .net
Ensuite que peut-on utiliser sur une carte à puce ? plein de trucs, par ex le bytecode java est plus compact que du code natif 32 ou 64 bits.
Par-contre foutre un buffer overflow sur une carte à puce me paraîtrait très con quand on connait la dose de techniques pour les éviter.
D'autre part je vois pas pourquoi un langage de haut niveau produirait des exécutables plus grs que les autre surtout si il y a du matos pour les faire tourner en hard.
Maintenant si personne ne se sort les doigts du cul pour dire aux hardeux qu'on aimerait passer la seconde au niveau fiabilité et qu'ils pourraîent nous aider ben ça bouge pas si ils voient un marché, ils se bougeront.
Des exemples simples : F-CPU prévoit un truc pour les langages fonctionnels, SPARC a des 'tag bits' pour différentier les pointeurs des entiers etc.
[^] # Re: Alors pourquoi mes fournisseurs ne me proposent que C et pas Eiffel ?
Posté par Moby-Dik . Évalué à -1.
"Un truc", la belle jambe. L'ensemble du jeu d'instruction est quand même tout à fait classique, et beaucoup plus proche de ce qu'on peut exprimer en C que du car/cdr :))
[^] # Re: Alors pourquoi mes fournisseurs ne me proposent que C et pas Eiffel ?
Posté par Gaël Le Mignot . Évalué à 4.
Et déplacer le problème vers le hard ? Vachement intelligent... Ca fait 20 ans qu'on est conscient que le RISC est plus adapté que le CISC, que l'on sait que le hard doit en faire le moins possible justement, que l'on déplace tout vers le soft (que ce soit avec des firmwares intégrés ou autre), et tu veux revenir en arrière ? C'est complétement stupide. Le hard c'est le plus critique, ce qui _doit_ absolument être exempt de bugs, il doit donc en faire le moins possible.
C'est comme quand on fait un OS: le noyau, la partie la plus critique, complexe à changer, où un problème peut avoir des conséquences désastreuses, _doit_ être le plus petit possible pour tout ce qui est sécurité.
Inégré une VM Java ou Caml au matos, c'est complètement stupide, c'est aller à l'encontre de tous les progrès et de toutes les recherches faites ces dernières années sur le fonctionnement des systèmes.
Relis donc un peu le chapitre sur la sécurité dans le Tanenbaum (ou tout autre bouquin sérieux sur la conception d'un système) par exemple "The only way to build a secure system is to keep it simple". Plus tu compliques le noyau d'un système, et a fortiori le matos, plus tu t'exposes à de graves problèmes.
Alors au lieu de t'énerver, d'insulter les gens et de te discréditer ainsi, essaie plutôt de réfléchir vraiment à comment concevoir un système fiable, et cesse de te fixer sur les langages de programmation qui ne sont qu'une _toute_ petite partie du problème.
[^] # Re: Alors pourquoi mes fournisseurs ne me proposent que C et pas Eiffel ?
Posté par Dugland Bob . Évalué à -2.
[^] # Re: Alors pourquoi mes fournisseurs ne me proposent que C et pas Eiffel ?
Posté par Étienne . Évalué à -2.
C'est comme quand on fait un OS: le noyau, la partie la plus critique, complexe à changer, où un problème peut avoir des conséquences désastreuses, _doit_ être le plus petit possible pour tout ce qui est sécurité.
Hehe on te vois venir avec ton Hurd Kilobug ;)
-1 que de mauvais esprit et absolument pas constructif avec une phrase de justification qui prend la moitié du post pour finalement arriver à un niveau d'intéret quasiment nul ; mais il parait que lorsqu'on répond à quelqu'un il faut en ecrire au moins autant de texte qu'on en cite alors je fait un effort pour remplir un peu mon post creu.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par TSelek . Évalué à 2.
écrire facilement du code non fiable sans s'en rendre compte
j'adore qu'on me prenne pour un imbécile, oh tu ne l'as pas écrit bien sur...
C permet d'écrire facilement du code non fiable
linux par exemple, l'est pas fiable du tout...
le monde du logiciel libre est particulièrement conservateur
C'est du FUD ? parce que le kernel est en C ? Moi j'ai vu plein de gens à la pointe sur XML, Ruby, Phython, Patterns Design, FreeNet, etc et qui faisaient bouger les choses... Et GNU en lui même n'est pas révolutionnaire ?
coder sous un système POSIX
NT aussi est POSIX. Qui est interessé par POSIX pour ce qu'il est ? peu de gens...
mais bon, je viens du hardware alors quand je vois des propos si utopiques, ça me laisse reveur...
Quand on code pour le plaisir, ce sont aussi les risques qu'on assume qui donne ce plaisir. C'est la bonne blague "l'asm c'est pour les hommes". À vaincre sans péril, on triomphe sans gloire.
Cela dit, tu serais terrorisé si tu savais le nombre de machines et d'automates que tu croises toute la journée et qui sont codés en C... et qui pourtant ne plantent pas pour autant (sauf les trucs MS bien sur).
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Miod in the middle . Évalué à 10.
Bien sûr ! Comme chacun des commentaires ici...
> écrire facilement du code non fiable sans s'en rendre compte
> j'adore qu'on me prenne pour un imbécile, oh tu ne l'as pas écrit bien sur...
Le mot clef était «permet». Je ne dis, ni ne sous-entend, que ceux qui codent en C sont des idiots. Cependant je maintiens que coder plus de 20000 lignes de C sans la moindre erreur est une tâche difficile.
> C permet d'écrire facilement du code non fiable
> linux par exemple, l'est pas fiable du tout...
Il suffit de constater que, version après version, une part non négligeable des changements sont des corrections de bugs, pour estimer que oui, Linux n'est pas fiable. Aucun logiciel n'est fiable d'ailleurs... Linux est suffisamment fiable pour répondre à la plupart des besoins, mais il n'y a pas de magie, dans plusieurs centaines de milliers de lignes de C, il y a toujours des erreurs, et pas uniquement parce qu'un driver a été écrit à partir d'un document constructeur lui-même erroné.
> le monde du logiciel libre est particulièrement conservateur
> C'est du FUD ? parce que le kernel est en C ? Moi j'ai vu
> plein de gens à la pointe sur XML, Ruby, Phython, Patterns Design,
> FreeNet, etc et qui faisaient bouger les choses...
> Et GNU en lui même n'est pas révolutionnaire ?
Non, ce n'est pas du FUD, c'est une simple constatation au fil du temps. Et le fait de coder un noyau en C n'est pas spécialement conservateur, mais plutôt un bon choix d'outil. On parlait des applications plus haut, ou les raisons d'utiliser le C plutôt qu'un autre langage sont moins importantes.
Quant à GNU, j'avoue ne pas trouver en quoi il serait révolutionnaire.
> mais bon, je viens du hardware alors quand je vois des
> propos si utopiques, ça me laisse reveur...
Et puis ? Moi aussi je viens du hardware. Et quand je code bas niveau, bien évidemment le C est l'un des outils les mieux adaptés.
> Cela dit, tu serais terrorisé si tu savais le nombre de
> machines et d'automates que tu croises toute la journée et
> qui sont codés en C... et qui pourtant ne plantent pas
> pour autant (sauf les trucs MS bien sur).
Pas plus que ça, vu que je suis responsable d'une partie de ces lignes de C (-:
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par TSelek . Évalué à -4.
Ben moi je trouve.
Et puis ma maman m'a dit de ne pas parler aux tenants de l'open source, que les gens de la FSF d'abord qu'elle m'a dit, sinon je finirai en enfer chez MS.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par monsieurw . Évalué à 3.
<< Why Software is so bad ... >>
http://www.msnbc.com/news/768401.asp?0si=-&cp1=1(...) .
(ça parle surtout de Windows -Msbnc oblige?- mais ça s'applique a priori à tout type de développement)
--
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par vrm (site web personnel) . Évalué à 4.
Aieee..
Gcc qui compile du C/C++/Java/Objective C/Fortran/Ada etc.. jusqu'a l'infini,
cherche un equivalent de suite de compilo cross platform supportant un collection de langage
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Toufou (site web personnel) . Évalué à 10.
Coder 20000 lignes sans erreur est une tâche difficile, il me semble.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Gaël Le Mignot . Évalué à 10.
Tu connais un OS à base de micro-noyau multi-serveurs qui soit réellement utilisable, toi ? T'appelle pas ça révolutionnaire ?
Tu connais un OS où si la pile TCP/IP ou le programme gérant un filesystem segfault il est relancé de manière de transparente dés la prochaine tentative d'utilisation ? Un OS où même un serveur ssh ou ftp peut s'exécuter sans avoir _aucun_ droit avant qu'on ne lui fournisse le login et le mot de passe ?
Tu connais un OS ou des utilisateurs normaux peuvent modifier la structure du VFS sans mettre en danger la sécurité ? Un OS où n'importe qui peut écrire de nouveaux composants insérables dans ce VFS sans aucun privilège (comme un translator fortune, un ftpfs ou un tarfs) ? Un OS où tu peux associer des pagers différents à chaque application ? Où tu peux créer un environement virtuel complet, dans lequel tu peux être virtuellement root, sans mettre en danger la sécurité du reste ?
Alors, avant de juger qu'un OS n'est pas révolutionnaire, regarde ce qu'est GNU, comment il est conçu et ce qu'il permet(tera) de faire.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Miod in the middle . Évalué à 4.
> soit réellement utilisable, toi ? T'appelle pas ça révolutionnaire ?
Non, je n'en connais pas. Et ne va pas prétendre que Hurd est utilisable dans l'état actuel des choses.
> Alors, avant de juger qu'un OS n'est pas révolutionnaire, regarde
> ce qu'est GNU, comment il est conçu et ce qu'il permet(tera) de faire.
D'une part, dans le propos de TSelek, j'avais compris «GNU» au sens «le projet GNU», pas «le système GNU». D'autre part, j'insiste, un système qui n'existe que sur le papier n'est pas révolutionnaire à mon avis. Quant le Hurd sera une réalité, je changerai peut-être d'avis.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Gaël Le Mignot . Évalué à -1.
1/ on dit _le_ Hurd
2/ le Hurd c'est pas un OS, et donc il ne sera jamais utilisable seul
3/ si tu parles du système GNU (GNU Mach + le GNU Hurd + la GNU libc + ...) oui, il est utilisable. Il est encore en développement, pas adapté à un serveur, mais il fonctionne et est utilisable.
D'une part, dans le propos de TSelek, j'avais compris «GNU» au sens «le projet GNU», pas «le système GNU».
Sauf que le système GNU est la raison d'être du projet GNU. Les outils GNU ont été réalisé pour servir de composant au système GNU et pour permettre de le développer... donc le projet GNU et le système GNU sont plus deux faces d'un même objet que deux choses différentes, et parler de l'un c'est parler de l'autre.
D'autre part, j'insiste, un système qui n'existe que sur le papier n'est pas révolutionnaire à mon avis.
Sauf qu'il n'est pas seulement sur le papier, et que ce dont j'ai parlé ça existe déjà. Ce qui manque c'est du test, de l'optimisation, du débuggage, et des fonctionalités, mais l'architecture du système existe et fonctionne à l'heure actuelle, et les possibilités dont je parlais ne sont pas hypothétiques mais réelles.
Quant le Hurd sera une réalité, je changerai peut-être d'avis.
http://www.debian.org/ports/hurd/(...)
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Romuald Delavergne . Évalué à 5.
Le langage a sans doute une part de responsabilité dans les bugs parce qu'il donne plus ou moins la possibilité d'en faire.
Mais le programmeur reste quand même le principal responsable. Rien n'empêche de bien programmer avec un "mauvais" langage si tu connais bien ses défauts.
Un mauvais ouvrier fera toujours du mauvais travail mais avec de bons outils.
Le choix d'un langage se fait sur possiblités, ses performances mais de plus en plus sur sa popularité. Donc je pense que le C a encore de beaux jours devant lui.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Dugland Bob . Évalué à -4.
Ceci dit un problème viens de l'endroit où tu demande à l'ouvrier de se concentrer, tu demande pas à un mec qui est sur une presse de 40 tonnes de se concentrer sur un truc en haut du cadre de la presse en disant "comme il est pas con" il va pouvoir surveiller sa presse en même temps.
Effectivement, il va pouvoir surveiller les 2 mais une des 2 taches n'est pas son métier et la sécurité veut qu'il se concentre sur un minimun de trucs.
Effectivement, le choix se fait par popularité, d'où cette politique du pire, c'est une véritable fuite en avant, il y a déjà eu des morts (missiles patriots, ambulances anglaises, systèmes de radiothérapie) mais bientôt ça va devenir régulier, tout ça pour "avoir fait comme les autres".
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Gaël Le Mignot . Évalué à 10.
Tu crois qu'il n'y a qu'en C qu'il y a des bugs ? Tu crois qu'en Java, en Caml, en Ada, en Python ou en VB y'en a pas des bugs ?!
Programmer en C, de manière sure, c'est parfaitement faisable il faut juste avoir un peu de méthode et faire gaffe à ce qu'on fait. Bien sûr quand on code on fait parfois des erreurs, mais c'est pareil dans _tous_ les langages.
C'est pas le langage qui fait un bon ou un mauvais programme, mais l'architecture globale du soft (le design) et les programmeurs (leur compétence, leur maîtrise du langage et le soin qu'ils ont mis à coder ce programme là). Et pour ça, le C n'est pas du tout un mauvais langage, parce qu'il peut assez facilement être _complêtement_ maîtrisé.
Alors cesse de crier contre le C à chaque trou de sécu d'un programme écrit en C. Regarde dans le monde MS, et tu verras que le C++ c'est pire. Enfin, non, c'est pas le C++ mais le logiciel propriétaire. Et pour les autres langages (Java, Caml, ...) ils ne sont pas viables pour un projet aussi critique niveau perf qu'un serveur Web.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Bin alors faudra m'expliquer pourquoi il y a des serveurs webs en 100% Java et qui tournent très bien ?
cf http://e-docs.bea.com/(...)
Ou en pike ?
cf http://caudium.net/(...)
Ou en python ?
cf http://www.zope.org/(...)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Gaël Le Mignot . Évalué à 9.
Pour http://e-docs.bea.com/(...) je ne connais pas, mais j'aimerais bien voir leurs perfs et leur tenue de charge...
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par benja . Évalué à -3.
<tentative de troll détectée>
On ne parlait pas de performance mais de fiabilité. C'est clair qu'un algo codé en C est généralement plus rapide mais cela ne sert à rien si le l'application est sujete à un DoS (voir une faille).
Justement -- pour répeter ce qui a été dit plus haut -- le programmeur qui ne doit pas se soucier de certains aspects (trop matériels), peut se concentrer sur les algos et, par conséquence, son application pourra être aussi performante.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Moby-Dik . Évalué à 6.
Pourtant le post précédent disait : "ils ne sont pas viables pour un projet aussi critique niveau perf qu'un serveur Web". Donc on parlait bien de performance.
C'est clair qu'un algo codé en C est généralement plus rapide mais cela ne sert à rien si le l'application est sujete à un DoS
Si tu te places dans une perspective académique, certes. Si tu es dans la vraie vie, que tu mets en place en serveur Web, et que tu as le choix entre :
- un machin en C/C++ rapide et léger mais qui a une espérance de plantage de deux ou trois heures par an à cause de bugs divers.
- un machin en SuperLangageHautNiveauApprouvéParMonProf blindé algorithmiquement, mais qui nécessite trois fois plus de mémoire et de CPU pour faire la même chose que le précédent, et qui va planter la machine en cas de pic de connexions car il va bouffer tout le swap.
... eh bien, si tu as ce choix, tu vas probablement décider de prendre le premier (ou alors c'est que tu décides mal). Une fois face à ce genre de problèmes, tu te fous de savoir si écrit en Javacaml, le bouzin serait potentiellement plus fiable d'après une hypothétique théorie du logiciel.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par bleh . Évalué à 2.
A vrai dire, ça dépends, si c'est pour mettre sur un pc de base, le premier s'impose, par contre, si t'as des alphaservers de production (comme on en voit chez des grosses boites) blindés en mémoire, tu t'en fous un peu qu'il bouffe de la RAM et du CPU. Le cout est epsilon face à ce que couterait en terme d'image et de remise en place un serveur tombé à cause d'un DoS ou d'un buffer overflow exploité par un pirate. On parle de pros là (à mon avis), pas de michel qui se monte son petit serveur pour montrer ses photos de vacance en Grèce.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Moby-Dik . Évalué à 4.
Mais bien sûuuuuuur :)) Si on te donne des alphaservers, c'est certainement parce qu'il y a un paquet de charge à soutenir, donc c'est pas avec un bouzin mal optimisé que tu t'en tireras.
Sinon, hormis les performances en calcul brut, je ne suis pas sûr que les alphas aujourd'hui soient beaucoup plus puissantes qu'un gros Xeon 2 GHz avec la mémoire en rapport. A voir ;)
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Thomas Cataldo (site web personnel) . Évalué à 1.
Bien sur il y a des bugs et il y (ou il y aura) des trous de sécurité trouvés dans ces serveurs, mais aucun ne permet de récupérer un shell en root.
A mon avis, il vaut mieux payer un serveur 500 euros plus cher (pour compenser les perfs infèrieures à celles d'apache) et choisir la sécurité, plutot que prier...
Pour les machines virtuelles java, la spec impose une phase de vérification des bytecodes qui vérifie que le compilo n'a pas fait n'importe quoi (hauteur de pile en entrée et à la sortie des méthodes, et pas mal d'autres choses).
Evidemment il faut que le produit soit 100% java. Pas un espèce de wrapper au dessus d'une librairie C.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Gaël Le Mignot . Évalué à 9.
Euh... tu me trouves un admin qui fait tourner Apache en root ? C'est vraiment pas prudent du tout ça...
Et avec un OS bien conçu (suivez mon regard) même un sshd, un telnetd ou autre ftpd n'a pas besoin des droits root (ni même d'aucun droit). La sécurité c'est d'abord dans le design général du système qu'elle se fait, pas dans le choix du langage.
Pour les machines virtuelles java, la spec impose une phase de vérification des bytecodes qui vérifie que le compilo n'a pas fait n'importe quoi (hauteur de pile en entrée et à la sortie des méthodes, et pas mal d'autres choses).
Oui, je sais, mais ça ça sert plus pour les applets ou autre (quand on exécute sur sa machine du code provenant de l'extérieur) pas pour ce qui est serveur (quand tu exécutes du code en qui tu as confiance).
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Marc (site web personnel) . Évalué à -2.
cf http://www.pugo.org:8080/(...)
Bon je sors
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Dugland Bob . Évalué à 2.
Relis ce que j'ai écrit plus haut à propos de l'attention.
qu'il peut assez facilement être _complêtement_ maîtrisé
Bon déjà non, la sémentique à rustine ça chie, si tu veux un langage parfaitement maîtrisable en 2 heures prends smalltalk, la grammaire tient sur un ticket de métro ou encore mieux prends Forth, elle tient sur le haut du ticket.
Ensuite je pense que tu parlais du comportement du programme plutôt que du langage ben là je suis pas d'accord non plus, je suis pas un compilateur et quand je code, je donne des ordres à la machine, je lui dit pas comment elle doit les exécuter, même en C c'est crétin de vouloir tout contrôler, tu va ralentir ton programme car tu maîtrise pas les timings des instructions, l'état des pipelines et de l'ordonanceur quand tu les prends, la dose d'inlining que tu peux te permettre (à cause du cache), etc.
Et tu va empêcher le compilo d'optimiser car tu auras été trop loin dans les détails de l'implentation mémoire de ton programme et il va être obligé de ce conformer à ce que tu lui auras dit.
Donc, *non*, je ne suis pas un compilateur.
Et si j'ai une représentation en tête de mon programme, je suis pas _du tout_ sûr qu'en mémoire il aura la même tronche.
L'exemple le plus simple : les CPS, le compilateur va virer derrière mon dos un paquet des appels de fonctions que j'ai écris (et les tranformer en saut direct) et bien qu'il le fasse, je m'en fout ! Mieux, ça limitera l'usage de la pile et conservera peut-être la partie active de la pile plus souvent dans le cache en plus ça vire les problèmes de récursivité sur certaines fonctions.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Moby-Dik . Évalué à 3.
Si c'est vraiment un critère pour toi, tu n'as qu'à prendre Intercal, ou l'assembleur 6502.
le compilateur va virer derrière mon dos un paquet des appels de fonctions que j'ai écris (et les tranformer en saut direct) et bien qu'il le fasse
M'étonnerait que les compilateurs C n'en soient pas capables, tu sais.
en plus ça vire les problèmes de récursivité sur certaines fonctions
Il y a peu d'algorithmes récursifs de façon inhérente. Injecter de la récursivité partout, c'est une contrainte foireuse des langages type Lisp. Ca rend le code difficilement lisible (quand un algorithme n'est par essence pas récursif, l'implémentation récursive est souvent tordue) et source de beaucoup d'erreurs potentielles (vérifier la réentrance, etc.).
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Dugland Bob . Évalué à -5.
Quand aux algos, j'ai jammais dit qu'il fallait tout récursiviser, il va falloir arrêter la mauvaise foi, j'ai dits que certaines fonctions récusives (récursives terminales et certaines autres, réécrites par le compilo) passaient tranquille. Les fonctions pas récursive .. bah c'est bien, qu'elles le restent.
Mais me tapper Trémaux à la main parce-que j'utilise un langage de merde, je préfère éviter.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Gaël Le Mignot . Évalué à 3.
C'est sûr que dans les autres langages tu n'as _jamais_ de problème d'ABI...
c'est la misère à compiler du C
Beaucoup moins que du C++ ou du Java... et même par rapport à du caml, c'est beaucoup plus simple à compiler efficacement.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Moby-Dik . Évalué à 4.
Oui, mais en fait on ne te demande pas trop si tu penses qu'ils en sont capables, mais plutôt s'ils le sont réellement. Là c'est un rideau de fumée que tu nous fais.
j'ai jammais dit qu'il fallait tout récursiviser, il va falloir arrêter la mauvaise foi
Tu ne l'as pas dit, par contre c'est à peu près ce qu'imposent les langages dont tu te fais l'avocat (caml...).
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Dugland Bob . Évalué à 2.
J'ai fait gaffe à pas privilégier de langage dans la discussion pour pas qu'il y ait un blaireau qui s'acharne dessus au lieu de réfléchir aux problème de son langage de 33l33t. Ce qui m'intéresse c'est une prise de conscience vis à vis du C pas de vendre un langage, au contraire, je suis pour l'ouverture, pas pour la fermeture dans un autre langage.
Tu devrais peut-être étudier le caml, puisque tu en parles :
http://caml.inria.fr/ocaml/htmlman/manual003.html#htoc7(...)
J'ai déjà parlé de langages fonctionnels purs (Haskell par ex.), mais je les recommande pas trop à n'importe qui, un changement brutal pourrait créer un rejet plus qu'autre chose (y'a qu'à déjà voir le fil de discussion ou je ne parlais que de changer le langage sans trop en pousser un autre).
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par bleh . Évalué à 3.
Moi personnellement, je vois quelque bonnes raisons de crier après le C. Je trouve qu'on oublie assez vite quelques trucs particulièrement aberrants :
- Les chaines de caractères et leur fonctionnement à la limite de la débilité (le délimiteur de fin chaine \0 ...). De nombreux langage ont une bien meilleure gestion des chaines de caractères, je citerais le Fortran histoire de bien insister sur cette faiblesse. Et avec les chaines, on peut aussi parler des fonctions telles que strlen qui peuvent donner de superbe résultats aberrants pour peu que le caractère nul soit "loin" dans la mémoire. Ne parlons pas des strcpy et consors qui sont des nids à buffer overflow.
- Le passage par valeur qui oblige à utiliser des pointeurs. En quelque sorte toucher à la mémoire en C est un passage obligé.
- La syntaxe qui peut très rapidement devenir cryptique pour peu qu'on ait à faire à un "3l33t c0d3rZ".
Enfin comme tu le disais, ce n'est pas le langage qui fait un bon ou un mauvais programme. Mais je ne peux pas m'empêcher de penser à bon nombre de programmeurs sur Amiga qui criaient au loup lorsqu'on parlait de contrôle mémoire sous prétexte que les programmeurs savent parfaitement gerer la mémoire tout seuls. Je trouve que nraynaud finalement pose une bonne question : est-ce que le C est toujours utilisé à bon escient ? A mon avis non, mais ça n'engage que moi.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Moby-Dik . Évalué à 2.
Ca doit être un troll :)) Vu que toute variable (à peu près) est stockée en mémoire quel que soit le langage, tout langage oblige à toucher à la mémoire... Rhha quelle horreur. Maintenant, si c'est le fait qu'il y ait des petites étoiles pour le signaler explicitement, tu peux toujours passer au C++, et les remplacer par des passages par référence.
La syntaxe qui peut très rapidement devenir cryptique pour peu qu'on ait à faire à un "3l33t c0d3rZ".
Humm. Tu en connais des langages qui empêchent de coder comme un porc ? (il vaudrait mieux que tu répondes non :-))
est-ce que le C est toujours utilisé à bon escient ? A mon avis non, mais ça n'engage que moi.
Bravo pour cette tautologie. Cite donc un langage toujours utilisé à bon escient :)
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par bleh . Évalué à 1.
Ben non, j'ai passé l'age.
Vu que toute variable (à peu près) est stockée en mémoire quel que soit le langage, tout langage oblige à toucher à la mémoire... Rhha quelle horreur. Maintenant, si c'est le fait qu'il y ait des petites étoiles pour le signaler explicitement, tu peux toujours passer au C++, et les remplacer par des passages par référence.
En effet, toutes les variables sont stockées en mémoire (ou presque) mais ça ne veut pas dire pour autant que tu touches explicitement à la mémoire. Tu n'as pas compris ce qui me gène dans le système de passage par valeur. Ca oblige à utiliser des pointeurs qui sont beaucoup moins pratiques à manipuler qu'une valeur brute. Exemple tu veux juste faire un petit calcul avec une variable passée à une fonction et voilà que tu es obligé de sortir la grosse artillerie pour pratiquement rien et ça ne se résume pas à mettre des "petites étoiles" comme tu dis.
Ensuite, si le passage par valeur n'est pas génant, je me demande pourquoi le C++ n'a pas uniquement adopté ce mode de passage. Le C++ corrige fort justement cette aberration en proposant le passage par références. Au moins tu as le choix d'utiliser des pointeurs quand c'est souhaitable et pas n'importe quand.
Enfin, le java non plus ne l'utilise pas, tu passes tes variables et tu te soucies peu de savoir comment fonctionne le mécanisme de passage parce que c'est transparent pour le programmeur.
Humm. Tu en connais des langages qui empêchent de coder comme un porc ? (il vaudrait mieux que tu répondes non :-))
Je connais des langages qui diminue cette facilité.
Au final, tu n'opposes pas grand chose à ce que je dis si ce n'est une légère moquerie (la partie sur les chaines de caractères a été soigneusement oubliée). Critiquer pas le C n'est pas le but en soi de mon post, j'ai assez pratiqué le C pour bien le connaître et l'aprécier mais je refuse de défendre bêtement ce qui n'est pas défendable. Dès qu'on parle du C ici, on a l'impression de toucher au Saint Graal. Je suis désolé mais il y'a des langages bien plus efficaces que le C.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par kael . Évalué à 1.
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Troy McClure (site web personnel) . Évalué à 1.
Maurice, tu pousses grand mère un peu trop dans les orties !
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Étienne . Évalué à 3.
- La syntaxe qui peut très rapidement devenir cryptique pour peu qu'on ait à faire à un "3l33t c0d3rZ".
Dans tous les langages, si tu as affaire à un goret y'a moyen de faire des trucs bien dégeulasse, même en Ada on voit des codes qui commencent par :
with ada.text_io;
with ada.integer_text_io;
with ...;
use ada.text_io;
use ada.integer_text_io;
use ...;
Et après on n'a plus que le nom des fonctions, à charge au relecteur de tout vérifier, sans parler du nom des variables i, x, p ou toto et celà dans n'importe quel langage.
Je veux bien qu'il soit plus facile de "bidouiller" dans certains langages, mais je pense que la propreté du code est d'abord l'affaire du programmeur.
Etienne
[^] # Re: c'est qd même un faiceau de preuves convergeant
Posté par Lionel Draghi (site web personnel) . Évalué à 1.
Eh, mais arrète ton obsession !
Tu crois qu'il n'y a qu'en C qu'il y a des bugs ? Tu crois qu'en Java, en Caml, en Ada, en Python ou en VB y'en a pas des bugs ?!
Bien sur que si, mais a niveau de qualité équivalent, tu aura juste passé deux fois moins de temps.
Programmer en C, de manière sure, c'est parfaitement faisable il faut juste avoir un peu de méthode et faire gaffe à ce qu'on fait. Bien sûr quand on code on fait parfois des erreurs, mais c'est pareil dans _tous_ les langages.
Non, ce n'est pas pareil dans tous les langages.
Les langages qui ont étés conçu en n'oubliant pas que la programmation est une activité humaine font en sorte de limiter les failles. Les autres tendent des pièges sans arrêt. Exemple, l'obligation d'utiliser pointeurs et allocation dynamique, le fait d'être case-sensitive, le fait de permettre la confusion entre affectation et comparaison, etc, etc.
De plus, les langages n'ont pas tous le même niveau d'abstraction. Que ce soit pour le codage (typage fort, interfacage avec le hard) ou la conception (gestion de la modularité, tasking, répartition) tous n'offent pas la même puissance. Ca n'est pas sans conséquence sur la productivité, et sur la qualité du résultat.
C'est pas le langage qui fait un bon ou un mauvais programme, mais l'architecture globale du soft (le design) et les programmeurs (leur compétence, leur maîtrise du langage et le soin qu'ils ont mis à coder ce programme là).
Non. Le langage a aussi une part importante. Quand on a découvert dans les années 70 que l'architecture était prépondérante, on a commencé a sortir ce lieu commun "peu importe le langage, pour peu qu'on ait le bon design".
Ca s'appelle jetter le bébé avec l'eau du bain. On a fait la même chose ensuite avec le support de l'objet versus le support de la modularité.
Un nouveau truc important n'efface pas les précédents, il s'ajoute. Je ne serai d'ailleurs pas surpris qu'on se remette à tout oublier avec l'arrivée de la vague AOP.
Et pour ça, le C n'est pas du tout un mauvais langage, parce qu'il peut assez facilement être _complêtement_ maîtrisé.
Oui, contrairement a C++. Mais ca ne compense pas ses faiblesses.
# ou l'art de retourner sa veste.
Posté par Francois SIMOND . Évalué à 10.
http://solutions.journaldunet.com/0206/020619_faille_apache.shtml(...)
arf!
les articles qui vont arriver sur le sujet vont pas être beaux a voir.
Comme d'hab, un serveur sous windows peut provoquer les pires crasses, mais faille encore non exploitée ( a priori ? ) dans un logiciel libre et c'est le modèle "opensource" qui ne vaut plus rien.
et hop, on en profite pou mettre dans un gros paquet l' "opensource"... :[
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# faille corrigée
Posté par rmrf1024 . Évalué à 7.
http://www.apache.org/dist/httpd/(...)
--------------
moins de 24Heures après, gnirf !!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.