l'aridité sans nom des types de bases (chaines de characteres et collections en tete),
En même temps, y'a pas de collections en C. Et les chaînes de caractères en C, elles sont ... ouai, bon, disons qu'elles sont légères. Lentes sur certaines opérations (strlen) mais légères en mémoire (1 octet gâché au lieu de sizeof (char*)).
c'est pas le premier langage qui me vient a l'esprit quand je pense simplicité.
C'est lequel?
Et j'aborde pas la gestion de la memoire, qui nous apporté tant de failles critique de sécurité ces 2-3 dernières années.
C'est vrai. Quand on touche la mémoire, on peut avoir des failles de sécurité.
Mais ce n'est pas une fatalité, particulièrement quand l'application est simple et le codeur propre.
Pour les failles de sécurité de ces dernières années, plusieurs auraient été détectées si:
le code n'avait pas été une usine à gaz (openssl)
la compilation avait été faite avec tous les warnings (code unreachable pour l'histoire du goto d'apple)
Par contre, pour les rares failles que je connais, c'est plus dur d'exploiter des failles en natif qu'en interprété.
[^] # Re: libuv : Cross-platform asynchronous I/O
Posté par freem . En réponse au journal Ulfius: framework pour faire des API Web en C. Évalué à 2.
En même temps, y'a pas de collections en C. Et les chaînes de caractères en C, elles sont ... ouai, bon, disons qu'elles sont légères. Lentes sur certaines opérations (strlen) mais légères en mémoire (1 octet gâché au lieu de
sizeof (char*)).C'est lequel?
C'est vrai. Quand on touche la mémoire, on peut avoir des failles de sécurité.
Mais ce n'est pas une fatalité, particulièrement quand l'application est simple et le codeur propre.
Pour les failles de sécurité de ces dernières années, plusieurs auraient été détectées si:
Par contre, pour les rares failles que je connais, c'est plus dur d'exploiter des failles en natif qu'en interprété.