Tout d'abord, merci de faire revenir la conversation au débat initial.
Tu es tres a cote de la verite. ce que vous traitez de dangereux depuis le debut, ce sont des erreurs de debutants, laxisme, ou etourderie.
Oui, des erreurs du programmeur qui conduisent à bugs non détectés par un compilo ou un runtime, et qui se transforme en faille de sécurité potentielle. D'où le danger.
Disons que c'est le coeur du débat : d'un côté on reporte la faute sur le programmeur qui s'est coupé avec le scalpel, de l'autre on indique qu'il y a des langages qui évite justement 90% des conneries de l'utilisateur qui avait juste besoin de se couper une tranche de saucisson.
Peu importe la fonction et le langage, si tu connais pas, il faut lire sa doc.
Justement non. C'est 2 visions totalement différentes, mais pour de nombreux programmeurs une API bien faite est une API intuitive, où je n'ai pas besoin d'utiliser la doc, ou peu. Le problème c'est pas qu'il n'y a pas d'API intuitive en C, le problème c'est que le langage est tellement dangereux qu'il est extrêment complexe de faire une API 100% secure : il est donc effectivement indispensable de lire la doc pour tous les aspects non-intuitif inhérent à l'environnement technique.
L'exemple du strncpy, qui se veut secure mais ne l'est pas à 100% est un très bon exemple : l'équivalent fonctionnel est parfaitement implémentable dans des langages "modernes" sans tous ces problèmes de documentation indispensable à sa bonne utilisation.
Si c etait aussi difficile que vous le dites, comment on a fait pour dev tous ces programmes en C, ainsi que ces OS ?
Ben vous le faites, mais avec pleins de problème de sécurité qui conduisent à des failles, pourtant "classiques", mais qui auraient été évités avec un langage de plus haut niveau.
Il y a plein de bonnes raisons d'utiliser le C pour coder un OS, mais la contrepartie est une forte exposition aux problèmes de sécurité.
[^] # Re: Dépassement de tampon
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Tout d'abord, merci de faire revenir la conversation au débat initial.
Oui, des erreurs du programmeur qui conduisent à bugs non détectés par un compilo ou un runtime, et qui se transforme en faille de sécurité potentielle. D'où le danger.
Disons que c'est le coeur du débat : d'un côté on reporte la faute sur le programmeur qui s'est coupé avec le scalpel, de l'autre on indique qu'il y a des langages qui évite justement 90% des conneries de l'utilisateur qui avait juste besoin de se couper une tranche de saucisson.
Justement non. C'est 2 visions totalement différentes, mais pour de nombreux programmeurs une API bien faite est une API intuitive, où je n'ai pas besoin d'utiliser la doc, ou peu. Le problème c'est pas qu'il n'y a pas d'API intuitive en C, le problème c'est que le langage est tellement dangereux qu'il est extrêment complexe de faire une API 100% secure : il est donc effectivement indispensable de lire la doc pour tous les aspects non-intuitif inhérent à l'environnement technique.
L'exemple du strncpy, qui se veut secure mais ne l'est pas à 100% est un très bon exemple : l'équivalent fonctionnel est parfaitement implémentable dans des langages "modernes" sans tous ces problèmes de documentation indispensable à sa bonne utilisation.
Ben vous le faites, mais avec pleins de problème de sécurité qui conduisent à des failles, pourtant "classiques", mais qui auraient été évités avec un langage de plus haut niveau.
Il y a plein de bonnes raisons d'utiliser le C pour coder un OS, mais la contrepartie est une forte exposition aux problèmes de sécurité.