> Pourquoi ne pas avoir fait dans la libc un lib 'secure' ?
Raisons historiques. J'etais pas la mais il me semble quand même qu'au moment de normaliser c'était déjà trop tard y'avait des implémentations pourries. Et le C c'est ultra conservateur à chaque fois qu'on risque de peter quelque chose on rajoute une tartine dans le norme pour rien casser. K&R & co n'avait pas prévu que leur langage sortirait de leur labo apparement :-)
> Dans enormément de cas c'est l'API qu'il faut remettre en cause
l'API de la libc est une sous merde. Je connais pas win32 mais je pense pas qu'il y ait plus utilisé et aussi mauvais que la libc; même dans les extensions sont attroces. Quand tu vois les socket par exemple...
Comme ca evolue pas, on se retrouve avec des extensions partout; et les uns ne veulent surtout pas des extensions des autres, c'est beaucoup plus pratique comme ca !
> pourquoi ne pas diriger les jeunes developpeurs vers des apis
mieux faites ?
Par ce que la plupart des profs de C sont completement a côté de la plaque et ne savent même pas utiliser strncpy(3) ou qu'il n'y a pas forcement de '0円'. Ca fait maintenant 3 ans que je fais du C en milieu scolaire j'ai jamais entendu prononcé une fois "buffer overflow" ou sécurité... Tu peux avoir 17 en programmant un shell qui repose sur des longjmp() dans un sighandler sans se proteger... La sécurité ca doit exister dans un monde parallèle mais pas ici.
Il est clair qu'une bonne alternative à la libc serait interessante. Je n'ai jamais mis la main sur un lib suffisament complète et documentée pour le moment par contre. Le mot de la fin, le C c'est le conservatisme à l'état pur, pour le meilleur comme pour le pire !
[^] # Re: glib
Posté par ckyl . En réponse au journal libc et sécurité.... Évalué à 1.
Raisons historiques. J'etais pas la mais il me semble quand même qu'au moment de normaliser c'était déjà trop tard y'avait des implémentations pourries. Et le C c'est ultra conservateur à chaque fois qu'on risque de peter quelque chose on rajoute une tartine dans le norme pour rien casser. K&R & co n'avait pas prévu que leur langage sortirait de leur labo apparement :-)
> Dans enormément de cas c'est l'API qu'il faut remettre en cause
l'API de la libc est une sous merde. Je connais pas win32 mais je pense pas qu'il y ait plus utilisé et aussi mauvais que la libc; même dans les extensions sont attroces. Quand tu vois les socket par exemple...
Comme ca evolue pas, on se retrouve avec des extensions partout; et les uns ne veulent surtout pas des extensions des autres, c'est beaucoup plus pratique comme ca !
> pourquoi ne pas diriger les jeunes developpeurs vers des apis
mieux faites ?
Par ce que la plupart des profs de C sont completement a côté de la plaque et ne savent même pas utiliser strncpy(3) ou qu'il n'y a pas forcement de '0円'. Ca fait maintenant 3 ans que je fais du C en milieu scolaire j'ai jamais entendu prononcé une fois "buffer overflow" ou sécurité... Tu peux avoir 17 en programmant un shell qui repose sur des longjmp() dans un sighandler sans se proteger... La sécurité ca doit exister dans un monde parallèle mais pas ici.
Il est clair qu'une bonne alternative à la libc serait interessante. Je n'ai jamais mis la main sur un lib suffisament complète et documentée pour le moment par contre. Le mot de la fin, le C c'est le conservatisme à l'état pur, pour le meilleur comme pour le pire !