Olivier Jeannet a écrit 1400 commentaires

est-ce que l'encodage Attention en bon français on dit codage. est-ce que le codage demande beaucoup de ressources processeur ? Avec la puissance des machines modernes, tu es tranquille, à moins d'avoir vraiment un vieux processeur. Le mieux est que tu télécharges l'appli et que tu essaies.

j'aime bien le mot coquille qui est utilisé pour désigner une erreur dans l'imprimerie

En fait c'est pour dire de façon polie qu'il y a une couille dans l'impression, ça date de l'époque où on travaillait avec des caractères en plomb; quand un "q" se glisse par inadvertance entre le "o" et le "u" ça donne : coquille
(je ne suis pas sûr à 100% de cette histoire mais c'est ce que j'ai entendu)

Je trouve franchement *lamentable* qu'ils aient oublié valgrind (GPL)

A la décharge de l'auteur de l'article :
- Valgrind est assez récent dans sa version 1.0
- il ne tourne pour l'instant que sur processeur x86
- Valgrind ralentit beaucoup l'exécution d'un programme (entre 20 et 50 fois j'ai entendu dire) car il émule le processeur

Moi, qui souffre de dysorthographie chronique, je n'ose plus faire un post sans m'être fait relire

Pas tant de crainte, on parle essentiellement de l'orthographe des nouvelles (les "news"), pas de celle des commentateurs (dont nous faisons partie).
Il est important que ce qui est publié par linuxfr soit le plus propre possible (et c'est possible car il y a un ou plusieurs modérateurs aptes à corriger, si nécessaire), après pour les commentaires on aura toujours des gens moins à l'aise avec le français, c'est normal.

Pour te rassurer, ton message est plutôt bien écrit.

Si l'on veut garder un site dynamique, laissez des personnes poster des news, et les modérateurs vérifier leur véracité.

Comme je le disais, les modérateurs ont tout loisir de corriger les fautes d'orthographe, même après publication. Avec environ 5 nouvelles par jour, ça devrait être jouable :-)

En effet, il faut faire attention à ce que les nouvelles soient irréprochables question orthographe, sinon ça manque de sérieux (le fond est important aussi bien sûr).
Tant qu'on y est, il reste 3 fautes mineures :
s/cette fois ci/cette fois-ci/
s/trés/très/
s/eux-meme/eux-même/

n'est-ce pas le boulot déjà de lhd.zdnet.com ?

Tu me coupes l'herbe sous les pieds :-)
Le site que tu mentionnes (Linux Hardware Database) est pas mal, je m'en suis servi déjà pour trouver de l'information sur une carte graphique mal supportée. Comme on peut y ajouter des commentaires, j'ai apporté ma contribution en mentionnant ma distribution, ma configuration et comment je m'en étais sorti.

C'est une allusion moulesque. Tout comme « intaigriste »

Heureusement qu'il y a des gens pour l'expliquer, même si avec le contexte j'avais fini par comprendre le second degré.

On devrait mettre ce genre de mot volontairement estropié en italique, ou entre pseudo-balises qui indiquent que c'est exprès (genre <moule>). Déjà qu'un nombre non négligeable de contributeurs ont du mal avec l'orthographe et la grammaire...

<troll> Ils étaient pas censés passer au système métrique les Etats-Uniens pour éviter de crasher des sondes sur Mars en confondant pied et mètre ?</troll>

:-)
(je souris de ta remarque mais c'est quand même super c*n et pas si drôle, en particulier pour ceux qui ont bossé des mois sur un tel projet)

Enfin bon on remarquera que le reste du monde n'a pas été outré et continue à vendre des disquettes de 8,89 cm et des écrans de 43,18 cm.

C'est vrai qu'on ne fait même plus gaffe, je pense en particulier aux écrans parce que les disquettes se font rares.
On a une exception avec le CD puisqu'il s'agit de 12 cm, qui n'est pas un multiple de pouce (à moins qu'il ne s'agisse de 4"3/4 = 12.065 cm ?)

un mélange d'égales quantités par le poids de neige et de NaCl (neige)

Alors, on joue au pédant avec son NaCl, au lieu de dire qu'il s'agit de bête sel ? :-) (je plaisante car tu t'es visiblement planté dans ta parenthèse)
Au fait le NaCl c'est du chlorure de sodium.

C'est pas du tout un troll, vu que la Debian est plus souple et plus simple a installer !

As-tu déjà installé une distribution commerciale récente ?

Qui peut faire + efficace que apt-get ??

Je pense que tu oublies que tu es un connaisseur, et que tu ne réalises pas les compétences informatiques d'une personne moyenne ! (d'ailleurs je me demande si ton message est sérieux...)

"apt-get chaipasquoi" c'est du chinois total pour quelqu'un de normal (déjà faut savoir ouvrir un terminal).
Ce que je dis ne retire rien à la qualité de la Debian et de apt-get, qui a prouvé son efficacité.

Correction d'une erreur courante :

... si Linus Thorvalds ...

C'est Linus Torvalds ! (sans le "h") (cf le texte de la nouvelle)

DB2, c'est aussi vachement plus performant et puissant que MySQL

MySQL étant réputé très rapide, sans doute à juste titre étant donné qu'il n'implémente pas tout le SQL et qu'il lui manque un certain nombre de fonctions avancées (triggers, procédures stockées, transactions, etc), as-tu des chiffres concrets ou des faits qui appuient ta déclaration ?
En tous cas dans le cas de volume de données pas trop important, j'ai du mal à croire que DB2 soit plus rapide que MySQL (sa relative simplicité le favorise).

C'est clair que c'est une très bonne nouvelle, même si ça va mettre du temps à se diffuser.

depuis le temps qu'on s'arrache les cheuveux a cause des formats de fichiers proprio qui circulent, notamment sur des sites d'administrations

J'ai eu la bonne surprise de pouvoir obtenir sur service-public.fr les formulaires pour l'achat et la vente de voiture d'occasion, et c'était uniquement en PDF. Pas besoin de se rendre à la préfecture, très agréable.

Vous n'aurez a priori même pas la capacité de le télécharger.

Je me demande comment ils vont pouvoir justifier ça, vu que Linux est en GPL, ils doivent fournir les sources si on leur demande.
C'est Stallman qui risque de se réveiller.

N'y aurait-il pas qqpart une liste des fonctions de la libc dont on peut être sûr

Houla pas tant d'inquiétude.
Toutes les fonctions sont potentiellement dangereuses, ça dépend comment tu t'en sers.
Que le strpcy() puisse être dangereux, c'est une question de bon sens car la copie s'arrête quand elle rencontre un '\0' (caractère de fin de chaîne en C), et s'il n'y a pas de zéro avant longtemps, la copie finit par déborder.
Pour faire un programme sûr, il faut ne pas faire confiance à ce qui entre (vérifier les tailles des paramètres, les valeurs pour les quantités). Pour la libc, de préférence utiliser les fonctions avec le "n" comme strncpy et snprintf, qui assurent de ne pas déborder le buffer dans lequel on écrit puisqu'on peut fixer une limite. Il suffit de regarder une fois la page de man pour les quelques fonctions de manipulation de chaîne que tu utilises, et c'est bon.
Je n'en ai pas sous la main mais il y a des URL qui t'expliquent comment programmer de la façon la plus sûre possible.

Parce que figure toi que le problème, il ne vient pas du strcpy()

Je ne suis pas d'accord, regarde ma réponse précédente à Iluvatar.

strncat(buffer, entry, sizeof(buffer)-strlen(buffer));

Il ne faut jamais perdre de vue que dans un buffer de taille n (char buffer[n]) on ne met réellement que n-1 caractères puisqu'il y a le '\0' terminal (en l'occurence les lignes 8 et 9 de ton exemple le prennent en compte).
Je pense que comme strncat rajoute un '\0' à la fin de buffer après avoir copié au max (sizeof(buffer)-strlen(buffer)) (cf la page de man), il faudrait mettre sizeof(buffer)-strlen(buffer) - 1
Je n'ai pas testé pour voir mais ça doit être la solution.

C'est pas le fait que strcpy soit utilisé qui pose problème ici

Et bien si justement, puisqu'avec un strcpy on prend le risque d'avoir le buffer copié plus grand que celui de destination. Il ne faut pas réfléchir plus loin, PAS DE strcpy.

La problématique ici, c'est les 2 appels successif à strncpy sans 0 terminal.

Le problème c'est que la personne qui a programmé ne sait pas lire la page de man (cf la remarque de PLuG plus bas).

void func(char *str) {
char buffer[12];
strcpy(buffer, str);
}

Tu es gentil, tu as utilisé un strcpy() !!
Montre-moi un programme vulnérable qui ne contient que des strncpy() bien utilisés.
La simple lecture de la fonction "func" m'a fait frémir avant même de lire la suite.
Et à quoi sert "arg2", il n'est pas utilisé ?

Tu sais, il y a aussi des buffer overflows qui sont exploitables avec les fonctions que tu proposes ? Ce n'est pas tout de dire qu'il faut les utiliser, encore faut-il le faire correctement.

Si tu as un exemple de buffer overflow avec strncpy() et snprintf() à montrer, je suis preneur, ça m'intéresse (sérieux).
Cela dit, tu as raison qu'il faut malgré tout utiliser correctement les fonctions en question. J'ai été étonné de voir des collègues sensés être expérimentés (plusieurs années) coder sans aucune sécurité. Personnellement (et pour répondre à ton titre) je teste toujours les valeurs de retour et je vérifie beaucoup de choses. C'est là qu'on voit que l'expérience a une valeur relative car des "petits jeunes" codent parfois beaucoup mieux qu'un supposé expérimenté.

Par exemple, sais-tu comment est géré la caractère de fin de chaîne pour les fonctions dont tu parles (et strncpy que tu as omis) ?

En cas d'oubli, un petit coup de "man strncpy" et c'est bon (je viens de le faire). Au fait je n'ai pas omis strncpy, j'en parlais justement dans mon message précédent (et tu l'as cité) ?!

il y a d'autres moyens d'arriver à des overflows (realpath(), gets(), scanf(), ...)

Il est déconseillé d'utiliser gets(), c'est même marqué dans la page de man : "No check for buffer overrun is performed (see BUGS below)", il est conseillé d'utiliser fgets() à la place.

Au fait, printf() ne permet pas de faire de buffer overflow que je sache (sprintf() oui puisqu'on écrit dans un buffer).

C'est que ce sont vraiment des bugs communs [...] En clair : buffers overflows et types de données mal utilisés.

Je ne vais pas être très constructif avec ce message mais je suis réellement surpris qu'on puisse encore laisser des bugs pareils. Ils utilisent encore des strcpy() et des sprintf() au lieu de strncpy() et snprintf() ? Ca donne envie de n'utiliser que des programmes écrits par Daniel Bernstein (qmail (mailer daemon sans faille connue), djbdns (bind mais sans trous), et j'en oublie) malgré la licence un peu restrictive (on ne peut pas redistribuer du code modifié sous le nom original, seulement des patches, il faut lui soumettre pour approbation et intégration), mais il ne peut pas tout faire !

Je suis encore plus surpris et déçu par OpenSSH, dont s'occupe Theo de Raadt, pour qui la sécurité justifiait un "fork" de OpenBSD. Quand on voit les bugs/trous de sécurité trouvés dans OpenSSH ces derniers mois, je crois me souvenir qu'il y a eu des "buffer overflow".

J'ai entendu parler récemment d'un analyseur de code capable de détecter une bonne partie des fonctions douteuses et des risques de bugs de sécurité. Quelqu'un se souvient de quoi il s'agit ?

> Mais c'est vrai que si tous le monde veut ecraser les autres
C'est pas le principe du capitalisme ?

:-)
Je fais une réponse sérieuse quand même.

Non, parmi ce qui définit le capitalisme, on a la libre disposition du travail (en gros, la liberté de choisir son employeur), l'organisation rationnelle du travail, la propriété privée.

On n'a pas attendu le capitalisme (qui s'est développé au 19e) pour voir les gens vouloir s'écraser les uns les autres, gagner de l'argent, etc...

Je croyais que c'etait en 2036 la fin du monde ...
(que ceux qui savent pas de quoi je parle, verifient le type de donnée utilisé pour coder une date en C ;)

Tu as dû rater les commentaires précédents (ou tu t'es trompé en calculant) parce que c'est début 2038 (janvier/février) qu'on aura des problèmes avec la date codée sur 32 bits, sur les systèmes de type Unix (au moins eux). C'est dû au fait que la date est codée en nombre de secondes depuis le 1/1/1970, et qu'elle est signée (par défaut une variable est signée).

Le calcul : il y a 31 536 000 secondes dans une année de 365 jours. Le plus grand entier signé est 2^31 - 1 = 2147483647. La division donne environ 68.096, soit 68 ans et 0.096*365 ~= 35 jours (je n'ai pas compté les années bissextiles, ça doit rapprocher la limite à mi-janvier).

parlons aussi des meteorite qui viennent du cote du soleil et que nous ne pouvons pas prevoir...

Comme on tourne autour du soleil pendant l'année, il n'y a pas de "météorite qui vient du côté du soleil", ça n'a pas de sens.
Il n'y a pas de zone d'ombre (si on peut dire :-) à cause du soleil dans l'observation du ciel.

il me semblait que le problème dit "des trois corps" était insoluble. Comment qu'y font, les balaizes de la NASA ?

On ne peut résoudre les équations de façon mathématique (avec une formule), mais ça fait bien longtemps qu'on fait de très bons calculs approchés. Rien qu'envoyer des gens sur la lune ça demande une bonne précision, et il y a au moins 3 corps en jeu (la terre, la lune, la fusée), sans compter le soleil. Rien que pour tirer d'affaire la capsule Apollo 13, pour la rentrée sur terre il fallait donner une poussée de quelques secondes à un moment bien précis et dans une direction précise au degré près (ceux qui ont vu le film doivent s'en souvenir).

Si à la fin des années 60 on savait faire ce genre de calcul, imagine la précision qu'on peut atteindre de nos jours avec la puissance des ordinateurs actuels. La précision des instruments d'observation a également bien augmenté. On a détecté la position (et la direction/vitesse) de cet astéroïde sachant qu'il arrive dans 17 ans, c'est impressionnant ! Quelqu'un sait à quelle distance de la terre il est ?

il adore le jeu

Cette expression est sans doute à rapprocher du titre du bouquin de Linus (Torvalds) : "just for fun". En effet, Linus a créé Linux juste pour le plaisir et pour s'amuser. C'est toujours sa motivation principale, il faut que ça l'amuse d'une façon ou d'une autre.

:wq
m#### !! pas sous vi ici ;-)

Marrant, je connais pas mal de gens qui tapent ":wq" pour sauver et quitter sous vi, alors qu'il est plus simple de taper ":x", ça sauve si c'est nécessaire et ça quitte.