1) Je ne vois pas l'avantage de coder des applications non-système en C. Pourquoi pas en assembleur, tant qu'on y est? C'est sûr, C permet de faire des trucs comme #define TRUERED(x) (((x) & 0xff0000) >> 8). Ça marche pour draguer?
2) Il n'y a pas nécessairement de rapport entre le nombre de lignes de code et l'efficacité ou la facilité de maintenance. Par exemple, pour st, on se retrouve avec un fichier st.c de 4000 lignes, et des centaines de fonction dedans. À part pour l'exploit de faire tenir un émulateur de terminal dans un fichier, c'est quoi l'intérêt?
3) L'exploit a un coût. Par exemple, le texte qui s'affiche quand on lance "st -h" est codé en dur. Du coup, quand on change une option, il faut modifier le code, et modifier le texte en dur. Il existe probablement des dizaines de bibliothèques qui permettent d'automatiser ça; beaucoup d'entre elles sont d'ailleurs seulement dans un .h et ne nécessitent pas de dépendance externes, elles peuvent juste être #include-ées.
Bref, l'exploit est intéressant en tant que tel, mais il est peut-être raisonnable de trouver un juste milieu. Les buffer overflow dans les applis météos parce qu'un geek a imaginé qu'il savait faire du C, ça va deux secondes, mais je préfère quand les gens utilisent des langages adaptés.
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 9.
Mouais.
1) Je ne vois pas l'avantage de coder des applications non-système en C. Pourquoi pas en assembleur, tant qu'on y est? C'est sûr, C permet de faire des trucs comme
#define TRUERED(x) (((x) & 0xff0000) >> 8). Ça marche pour draguer?2) Il n'y a pas nécessairement de rapport entre le nombre de lignes de code et l'efficacité ou la facilité de maintenance. Par exemple, pour st, on se retrouve avec un fichier st.c de 4000 lignes, et des centaines de fonction dedans. À part pour l'exploit de faire tenir un émulateur de terminal dans un fichier, c'est quoi l'intérêt?
3) L'exploit a un coût. Par exemple, le texte qui s'affiche quand on lance "st -h" est codé en dur. Du coup, quand on change une option, il faut modifier le code, et modifier le texte en dur. Il existe probablement des dizaines de bibliothèques qui permettent d'automatiser ça; beaucoup d'entre elles sont d'ailleurs seulement dans un .h et ne nécessitent pas de dépendance externes, elles peuvent juste être #include-ées.
Bref, l'exploit est intéressant en tant que tel, mais il est peut-être raisonnable de trouver un juste milieu. Les buffer overflow dans les applis météos parce qu'un geek a imaginé qu'il savait faire du C, ça va deux secondes, mais je préfère quand les gens utilisent des langages adaptés.